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

[proxy] Forward the `server:` header if present #1226

Merged
merged 2 commits into from Mar 15, 2017

Conversation

Projects
None yet
2 participants
@deweerdt
Member

deweerdt commented Mar 13, 2017

Looking at https://tools.ietf.org/html/rfc7231#section-7.4.2 I couldn't find a rationale that makes the header explicitly one hop. OTOH, forwarding the header if present does help with interop. Please let me know if you'd prefer a knob to make this configurable.

@kazuho

This comment has been minimized.

Show comment
Hide comment
@kazuho

kazuho Mar 14, 2017

Member

@deweerdt Thank you for the PR.

Looking at https://tools.ietf.org/html/rfc7231#section-7.4.2 I couldn't find a rationale that makes the header explicitly one hop.

As specified in the section, a server header is used to indicate the origin server being used. So it is appropriate to set h2o as the value of the header. H2O is a content server or a gateway (a.k.a. reverse proxy). Note that in both case, the server is an origin server in terms of HTTP. Quoting from RFC 7230 section 2.3:

A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as an origin server for the outbound connection but translates received requests and forwards them inbound to another server or servers. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance through "accelerator" caching, and to enable partitioning or load balancing of HTTP services across multiple machines.

Regarding interop, the value of the header has historically being used to blacklisting buggy peers. So transferring the server header sent by the content server might cause issues. But there could be benefits in transferring the value set by the content server. I would appreciate it if you could clarify what you have in your mind.

Member

kazuho commented Mar 14, 2017

@deweerdt Thank you for the PR.

Looking at https://tools.ietf.org/html/rfc7231#section-7.4.2 I couldn't find a rationale that makes the header explicitly one hop.

As specified in the section, a server header is used to indicate the origin server being used. So it is appropriate to set h2o as the value of the header. H2O is a content server or a gateway (a.k.a. reverse proxy). Note that in both case, the server is an origin server in terms of HTTP. Quoting from RFC 7230 section 2.3:

A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as an origin server for the outbound connection but translates received requests and forwards them inbound to another server or servers. Gateways are often used to encapsulate legacy or untrusted information services, to improve server performance through "accelerator" caching, and to enable partitioning or load balancing of HTTP services across multiple machines.

Regarding interop, the value of the header has historically being used to blacklisting buggy peers. So transferring the server header sent by the content server might cause issues. But there could be benefits in transferring the value set by the content server. I would appreciate it if you could clarify what you have in your mind.

@kazuho

This comment has been minimized.

Show comment
Hide comment
@kazuho

kazuho Mar 14, 2017

Member

PS. all in all, I think that having a knob is not a bad thing. However I believe that the default should be to drop the value sent by the content server, and that the code should make sure that multiple server headers are not emitted when send-server-name is set to ON.

Member

kazuho commented Mar 14, 2017

PS. all in all, I think that having a knob is not a bad thing. However I believe that the default should be to drop the value sent by the content server, and that the code should make sure that multiple server headers are not emitted when send-server-name is set to ON.

deweerdt added some commits Mar 13, 2017

[proxy] add an option to preserve the backend's server: header
Add `preserve` as a possible value for `send-server-name`. When this
value is set, H2O will:
- Forward the value received from the backend when proxying
- Not send the server name
@deweerdt

This comment has been minimized.

Show comment
Hide comment
@deweerdt

deweerdt Mar 15, 2017

Member

@kazuho thank you for your comments. 0ddd57a makes this change an option controlled by a new preserve value that can be set to send-server-name. I've also rebased the branch on current master + added test coverage

Member

deweerdt commented Mar 15, 2017

@kazuho thank you for your comments. 0ddd57a makes this change an option controlled by a new preserve value that can be set to send-server-name. I've also rebased the branch on current master + added test coverage

@kazuho kazuho merged commit be55e67 into h2o:master Mar 15, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@kazuho

This comment has been minimized.

Show comment
Hide comment
@kazuho

kazuho Mar 15, 2017

Member

Thank you for the changes! Merged to master.

Member

kazuho commented Mar 15, 2017

Thank you for the changes! Merged to master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment