-
Notifications
You must be signed in to change notification settings - Fork 868
server timing tiny improvements #1818
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
Conversation
|
Am I correct in assuming that you can resume your work on this PR now that #1819 has been merged? |
|
Added some more improvements and changes:
and server-timing trailers can be always discarded, so there's no problem to send that trailer without a request explicitly contains
|
|
I really like how simple the code has become (including the omission of
Thank you for noting that. It is indeed a behavior change. My understanding is that the mapping between the configuration and when the trailer will be emitted becomes like the table shown below.
Previously, the entry marked with the star (*) behaved differently; trailers were only emitted if the request contained a TE header. So the deployments that will be affected by this change are the ones that use As an upstream maintainer, I do not have a strong opinion. @deweerdt Thoughts? |
|
FTR, we agreed that not checking the existence of TE is fine. If people see interoperability issues due to HTTP/1.1 clients with broken chunked decoders, we could talk about a) reintroducing the check or b) introducing a "unless-h1" configuration knob, that forbids the use of server-timing trailers when HTTP/1.1 is being used. |
This PR does 2 tiny improvements on server-timing feature:
trailer: server-timingheader when h2o cannot send trailers (e.g. cannot use chunked encoding)send_server_timing_[header|trailer]flags bit ORs of property groups (BASICfor connect, request-total, etc andPROXYfor `proxy-*). This doesn't change current behavior at all but it'll bring flexibility to add/remove property groups in future/fork development.