-
Notifications
You must be signed in to change notification settings - Fork 22
Add support for non-ASCII header values #26
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
Changes from all commits
c0b92ab
17ed5a1
a7a3a0d
3a50dce
dfa0134
4531f81
fe15c58
4ea1105
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -119,8 +119,10 @@ public static boolean isURICharacter(byte ch) { | |
return ch >= '!' && ch <= '~'; | ||
} | ||
|
||
// RFC9110 section-5.5 allows for "obs-text", which includes 0x80-0xFF, but really shouldn't be used. | ||
public static boolean isValueCharacter(byte ch) { | ||
return isURICharacter(ch) || ch == ' ' || ch == '\t' || ch == '\n'; | ||
int intVal = ch & 0xFF; // Convert the value into an integer without extending the sign bit. | ||
return isURICharacter(ch) || intVal == ' ' || intVal == '\t' || intVal == '\n' || intVal >= 0x80; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In addition to header values, this method is used when parsing the response status message. Does the RFC allow for this type of character there as well? Or is there any risk to using this same logic for both of these use cases? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That part hasn't been superseded by RFC9110, so according to RFC7230, the status reason can still (unfortunately) contain
|
||
} | ||
|
||
/** | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose this should be ok? We will be allocating at least 4k on each request - this is quite a bit more than the previous
StringBuilder
- but I suppose that was likely having to re-allocate the underlying array right away.Perhaps it is very common for the HTTP request preamble to exceed 4k? Any performance concern on this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I presume the previous approach did a lot of re-allocations and copying while it was parsing the prelude. This feels large enough to not need re-allocation in most cases, while not going overboard.