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

Requirements for a cohttp proxy #501

Open
dave-tucker opened this Issue Jul 26, 2016 · 1 comment

Comments

Projects
None yet
2 participants
@dave-tucker

dave-tucker commented Jul 26, 2016

As mentioned in #498 I'm looking at implementing an http proxy using cohttp.
Having read through RFC2616, RFC7230 and RFC7231 there are some interesting requirements.

I thought it would be helpful to list them here so features can be added, or tests written for each requirement.

  • Ensure that unrecognized header fields are forwarded (RFC 7230 3.2.1) unless the are specified in the Connection header
  • A proxy must not change the order of duplicated header fields (RFC 7230 3.2.2)
  • A proxy must remove any whitespace between the header field-name and colon before forwarding a response (RFC 7230 3.2.4)
  • A proxy that receives an obs-fold in a response message that is not within a message/http container MUST either discard the message and replace it with a 502 (Bad Gateway) response (RFC 7230 3.2.4)
  • If a message is received without a Transfer-Encoding header and with differing or invalid Content-Length headers a proxy must discard the response and send a 502 (Bad Gateway) response to a client. (RFC 7230 3.3.3)
  • If a proxy receives an OPTIONS request with an absolute-form of request-target in which the URI has an empty path and no query component, then the last proxy on the request chain MUST send a request-target of "*" when it forwards the request to the indicated origin server. (RFC 7230 5.3.4)
  • When a proxy receives a request with an absolute-form of request-target, the proxy MUST ignore the received Host header field (if any) and instead replace it with the host information of the request-target. A proxy that forwards such a request MUST generate a new Host field-value based on the received request-target rather than forward the received Host field-value. (RFC 7230 5.4)
  • A proxy MUST send an appropriate Via header field, as described below, in each message that it forwards (RFC 7230 5.7.1)
  • A proxy or gateway MUST parse a received Connection header field before a message is forwarded and, for each connection-option in this field, remove any header field(s) from the message with the same name as the connection-option, and then remove the Connection header field itself (or replace it with the intermediary's own connection options for the forwarded message) (RFC 7230 6.1)
  • A proxy MUST NOT automatically retry non-idempotent requests (RFC 7230 6.3.1)
  • Support for OPTIONS "ping" to discover HTTP/1.1 conformance (RFC 7231 4.3.7)
  • Support for proxying of Expect (RFC 7231 5.1.1)
  • Support for forwarding of 1xx headers unless we added them (RFC 7231 6.2)
  • A proxy MUST NOT generate a Vary field with a "*" value (RFC 7231 7.1.4)
  • A proxy MUST NOT modify the Allow header field (RFC 7231 7.4.1)

/cc @avsm

@avsm

This comment has been minimized.

Show comment
Hide comment
@avsm

avsm Jul 26, 2016

Member

A proxy must not change the order of header fields

This is not accurate. To quote RFC 7230 3.2.2:

The order in which header fields with the same field name are received is therefore significant to the interpretation of the combined field value; a proxy MUST NOT change the order of these field values when forwarding a message.

It's ok to rearrange independent headers, but for duplicate headers the order is significant since they are normalised by concatenating them in the order they are received.

In practise it'll be expensive for Cohttp to preserve the order of other fields since we sort them into a Map. We can preserve it if we want, but its not necessary according to the spec.

Member

avsm commented Jul 26, 2016

A proxy must not change the order of header fields

This is not accurate. To quote RFC 7230 3.2.2:

The order in which header fields with the same field name are received is therefore significant to the interpretation of the combined field value; a proxy MUST NOT change the order of these field values when forwarding a message.

It's ok to rearrange independent headers, but for duplicate headers the order is significant since they are normalised by concatenating them in the order they are received.

In practise it'll be expensive for Cohttp to preserve the order of other fields since we sort them into a Map. We can preserve it if we want, but its not necessary according to the spec.

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