W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

clarify some MUST requirements in HTTPbis part 1 section 3.3

From: Dmitry Kurochkin <dmitry.kurochkin@measurement-factory.com>
Date: Tue, 29 Nov 2011 06:05:14 +0400
To: HTTP Working Group <ietf-http-wg@w3.org>
Cc: Alex Rousskov <rousskov@measurement-factory.com>
Message-ID: <87wrajvg2t.fsf@gmail.com>
Hello.

HTTPbis part 1 section 3.3 has the following requirements:

  If more than one Transfer-Encoding header field is present in a
  message, the multiple field-values MUST be combined into one
  field-value, according to the algorithm defined in Section 3.2, before
  determining the message-body length.

  If a message is received that has multiple Content-Length header
  fields (Section 8.2) with field-values consisting of the same decimal
  value, or a single Content-Length header field with a field value
  containing a list of identical decimal values (e.g., "Content-Length:
  42, 42"), indicating that duplicate Content-Length header fields have
  been generated or combined by an upstream message processor, then the
  recipient MUST either reject the message as invalid or replace the
  duplicated field-values with a single valid Content-Length field
  containing that decimal value prior to determining the message-body
  length.

It is not clear whether proxies that do not reject the message MUST
replace the duplicated field-values in the forwarded message.  In other
words, are non-transforming proxies required to either reject or fix the
message?

Should the specs require connection closure to prevent message smuggling
in naive implementations that respond with an error to "reject the
message" but then keep the connection open/persistent?  The specs are
explicit about this in item #3 where they talk about "framing" error,
but not here, where essentially the same framing error is suspected if
the message is rejected.

Also, should the specs be more specific regarding what connection
(upstream or downstream) proxy is required to close?

  If this is a response message received by a proxy, the proxy MUST
  discard the received response, send a 502 (Bad Gateway) status code as
  its downstream response, and then close the connection.

Above can be interpreted that the downstream connection must be closed.
But the proxy should only close the upstream connection.  Moreover, the
"then" word is wrong there as there is no need to keep that connection
open while the 502 response is being sent.  The order of those actions
should be up to the proxy to decide.

The fixed text may read:

  If this is a response message received by a proxy, the proxy MUST
  discard the received response, close the upstream connection, and send
  a 502 (Bad Gateway) status code response as its downstream response.

Regards,
  Dmitry
Received on Tuesday, 29 November 2011 02:06:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:50 GMT