[Mod_gzip] Re: The lower case header patch also fixes another problem.

[mod_gzip@lists.over.net]

Hi Jin,


> I just found the lower case header patch sent to you yesterday
> also fix another problem, which is caused by a low case header
> "content-length" set by the commercial java application server
> I am using.
> Without that patch, the HTTP response will have two "content-length"
> headers set, one is from the java app server, the other is from
> mod_gzip, which can cause some browsers like IE(5.5 ~ 6.0) to
> hang up on receiving the response.(however, mozilla and opera are OK)
>
> The following is a 'wget -S --header "Accept-Encoding: gzip" some_url'
> output before patching. Note the two content-length headers
> ####################################################
> 1 HTTP/1.1 200 Apple
> 2 Date: Tue, 29 Apr 2003 20:40:21 GMT
> 3 Server: Apache/1.3.27
> 4 connection: keep-alive, Keep-Alive
> 5 content-length: 14505
> 6 Keep-Alive: timeout=15, max=100
> 7 Content-Type: text/html
> 8 X-Pad: avoid browser bug
> 9 Content-Encoding: gzip
> 10 Content-Length: 2695
> ####################################################
>
> The following is the  'wget -S --header "Accept-Encoding: gzip"
> same_url' output after patching.
> ####################################################
> 1 HTTP/1.1 200 Apple
> 2 Date: Tue, 29 Apr 2003 20:43:08 GMT
> 3 Server: Apache/1.3.27
> 4 connection: keep-alive, Keep-Alive
> 5 Keep-Alive: timeout=15, max=100
> 6 Content-Type: text/html
> 7 X-Pad: avoid browser bug
> 8 Content-Encoding: gzip
> 9 Content-Length: 2694
> ####################################################
>
> We can see header character cases can sometimes cause relatively
> more serious problems than we expect. :)

again, many thanks for posting this problem!

A copy of this mail goes to the mod_gzip mailing list to
inform the users about this effect.



And the deeper I look into this issue, the more I am wondering
what else might happen when applications use HTTP/1.1 to its
full extent.

Just have a glance at RFC 2616, Chapter 4.2
     (http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2)
where I am reading:
     "Header fields can be extended over multiple lines by preceding
      each extra line with at least one SP or HT.
      Applications ought to follow "common form", where one is known
      or indicated, when generating HTTP constructs, since there might
      exist some implementations that fail to accept anything beyond
      the common forms."
So, what if applications choose to _not_ follow the "common
form"? Would mod_gzip handle multi-line HTTP headers correctly,
when it already fails to handle them correctly in respect of
case sensitivity?

And then, reading on:
     "Multiple message-header fields with the same field-name MAY be
      present in a message if and only if the entire field-value for
      that header field is defined as a comma-separated list [i.e.,
      #(values)].
      It MUST be possible to combine the multiple header fields into
      one "field-name: field-value" pair, without changing the
      semantics of the message, by appending each subsequent
      field-value to the first, each separated by a comma.
      The order in which header fields with the same field-name are
      received is therefore significant to the interpretation of the
      combined field value, and thus a proxy MUST NOT change the order
      of these field values when a message is forwarded."
Which explicitly states that the current behaviour of mod_gzip
is _not_ compliant with RFC 2616, as two "Content-Length:"
headers with _different_ values surely cannot be combined to
one header without selecting one of these two values, and thus
changing their (undefined) semantics into a defined one.

Regards, Michael