Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(client): add support for title case header names at the socket level #1497

Merged
merged 1 commit into from
Apr 24, 2018
Merged

feat(client): add support for title case header names at the socket level #1497

merged 1 commit into from
Apr 24, 2018

Conversation

mbilker
Copy link
Contributor

@mbilker mbilker commented Apr 23, 2018

This introduces support for the HTTP/1 Client to write header names as title case when encoding
the request.

Need to work on tests.

Closes #1492

Copy link
Member

@seanmonstar seanmonstar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome! Great start!

@@ -649,6 +655,7 @@ impl fmt::Debug for State {
.field("keep_alive", &self.keep_alive)
.field("error", &self.error)
//.field("method", &self.method)
.field("title_case_headers", &self.title_case_headers)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking that perhaps this field shouldn't be logged, since the State gets dumped somewhat frequently to help debug the current state, and seeing this longer field being the same constant forever will just be noisy.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with that reasoning. Should it be commented like the method field to indicate it isn't logged or just get rid of the line entirely?

write_headers_title_case(&head.headers, dst);
} else {
write_headers(&head.headers, dst);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since there's no way to set this for the server yet (and I'm tempted to leave it out until someone asks for it), the bool check is kind of a waste. Whatcha think of removing it from the ServerTransaction version here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since ServerTransaction implements Http1Transaction, I cannot just remove it from the method signature as that would deviate from the trait definition, but I can prefix it with an underscore to signify that the boolean is unused.

// Write header names as title case. The header name is assumed to be ASCII,
// therefore it is trivial to convert an ASCII character from lowercase to
// uppercase. It is as simple as XORing the lowercase character byte with
// space.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this will get a couple characters changed completely. Specifically, | and ~ will become \\ and ^, respectively. Probably not super common, but it'd be a semantic change...

Also, it'd be nice to include some tests of title_case, perhaps at the bottom of the file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I forgot to think of those. A check to see if the byte falls between 97 (a) and 172 (z) should suffice.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The z byte is 122, not 172 :D

Actually, to make it clearer, you can just write b'a' and b'z', which the compiler sees as the meaning the ASCII byte of the character.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I read the octal field by accident from the man page. I fixed it to a >= b'a' and <= b'z'.

@mbilker
Copy link
Contributor Author

mbilker commented Apr 24, 2018

I noticed that the encode methods are not tested at the bottom of the file, but they are heavily tested in the integration tests of Client. I will add some tests for the title_case method and some integration tests to check for title cased headers through the client request.

Copy link
Member

@seanmonstar seanmonstar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking great! Just one bug around checking for z...

@@ -857,6 +901,21 @@ mod tests {
Client::decoder(&head, method).unwrap_err();
}

#[test]
fn test_client_request_encode_title_case() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, awesome!

This introduces support for the HTTP/1 Client to write header names as title case when encoding
the request.

Closes #1492
@mbilker
Copy link
Contributor Author

mbilker commented Apr 24, 2018

I modified the client integration test macros to accept a title_case_headers parameter and I added a test using said change to ensure the client is encoding the headers as title case.

If you feel that this change is unnecessary because of the unit test, then I can revert that file back to its original state.

@mbilker
Copy link
Contributor Author

mbilker commented Apr 24, 2018

Hmm. The tests passed on my computer, but on Travis they flat out fail or crash.

Let me know if they crash on your computer.

@seanmonstar
Copy link
Member

The tests in CI failing are unrelated. I'm battling a race condition in the futures mpsc channel implementation, and still haven't gotten it working always, it seems.

@seanmonstar seanmonstar merged commit a02fec8 into hyperium:master Apr 24, 2018
@seanmonstar
Copy link
Member

It looks good to me, thanks!

@mbilker mbilker deleted the h1_title_case_headers branch April 24, 2018 23:41
@mbilker
Copy link
Contributor Author

mbilker commented Apr 24, 2018

Thank you very much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants