Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@i110
Copy link
Contributor

@i110 i110 commented Jul 31, 2018

This PR does 2 tiny improvements on server-timing feature:

  1. suppress trailer: server-timing header when h2o cannot send trailers (e.g. cannot use chunked encoding)
  2. make send_server_timing_[header|trailer] flags bit ORs of property groups (BASIC for connect, request-total, etc and PROXY for `proxy-*). This doesn't change current behavior at all but it'll bring flexibility to add/remove property groups in future/fork development.

@kazuho
Copy link
Member

kazuho commented Aug 9, 2018

Am I correct in assuming that you can resume your work on this PR now that #1819 has been merged?

@i110
Copy link
Contributor Author

i110 commented Aug 9, 2018

Added some more improvements and changes:

  1. 0be7169 Removed checks for TE: trailers existence in ON mode. I think that is unnecessary because RFC7230 4.1.2 says:
Unless the request includes a TE header field indicating "trailers"
   is acceptable, as described in Section 4.3, a server SHOULD NOT
   generate trailer fields that it believes are necessary for the user
   agent to receive.  Without a TE containing "trailers", the server
   ought to assume that the trailer fields might be silently discarded
   along the path to the user agent.

and server-timing trailers can be always discarded, so there's no problem to send that trailer without a request explicitly contains TE: trailers. @deweerdt @kazuho Please let me know if you think it's not correct or unacceptable.

  1. b069393 Then we don't need send_server_timing_trailers flag!

@kazuho
Copy link
Member

kazuho commented Aug 9, 2018

I really like how simple the code has become (including the omission of send_server_timing_trailers). Thank you @i110 for your work.

  1. 0be7169 Removed checks for TE: trailers existence in ON mode.

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.

setting \ protocol HTTP/1.1 with content-length HTTP/1.1 without content-length h2
off no trailers no trailers no trailers
on no trailers emit trailers* emit trailers
enforce drop c-l, emit trailers emit trailers emit trailers

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 on as the configuration. When they emit a trailer to a HTTP/1.1. client with broken trailer support, things might go wrong.

As an upstream maintainer, I do not have a strong opinion.

@deweerdt Thoughts?

@i110 i110 merged commit bd64950 into master Aug 9, 2018
@kazuho
Copy link
Member

kazuho commented Aug 9, 2018

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.

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.

3 participants