http-protocol.pac parsing error on HTTP 1.1 folded headers

Zeek
1

I’ve found an interesting binpac parse error when parsing http headers from www.golfsmith.com using http-protocol.pac. The problem is that the golfsmith server is replying with a header that http-protocol.pac is interpreting as corrupt.

Here’s an example of the golfsmith.com headers
HTTP/1.1 200 OK
Server: Apache/2.2.6 (Unix) mod_ssl/2.2.6
DAV/2 PHP/5.2.5
X-Powered-By: PHP/5.2.5
Content-Type: text/html

Note the line DAV/2 that is started with a space. That’s where the parsing error occurs. However, it seems like this may actually be legal according to the standards.

RFC2616 section 2.2 indicates that
“HTTP/1.1 header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream.”

According to this section, the www.golfsmith.com header “Server:” is broken across the two lines, and it’s value is actually “Apache/2.2.6 (Unix) mod_ssl/2.2.6DAV/2 PHP/5.2.5”

Does anyone have ideas on how http-protocol.pac should be modified to handle this situation?

Thanks,
Kelvin Edmison

2

Hi Kelvin,

Sorry for the late reply (I missed the email in my inbox).

I've found an interesting binpac parse error when parsing http headers from
www.golfsmith.com using http-protocol.pac. The problem is that the
golfsmith server is replying with a header that http-protocol.pac is
interpreting as corrupt.

Here's an example of the golfsmith.com headers
HTTP/1.1 200 OK
Date: Fri, 01 Feb 2008 17:10:30 GMT
Server: Apache/2.2.6 (Unix) mod_ssl/2.2.6
DAV/2 PHP/5.2.5
X-Powered-By: PHP/5.2.5
Content-Type: text/html

Note the line DAV/2 that is started with a space. That's where the parsing
error occurs. However, it seems like this may actually be legal according
to the standards.

RFC2616 section 2.2 indicates that
"HTTP/1.1 header field values can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab. All linear white
space, including folding, has the same semantics as SP. A recipient MAY
replace any linear white space with a single SP before interpreting the
field value or forwarding the message downstream."

Yes, you are right. This is legal and the original Bro HTTP analyzer handles it.

According to this section, the www.golfsmith.com header "Server:" is broken
across the two lines, and it's value is actually "Apache/2.2.6 (Unix)
mod_ssl/2.2.6<LF><SP>DAV/2 PHP/5.2.5"

Does anyone have ideas on how http-protocol.pac should be modified to handle
this situation?

I think the current http-protocol.pac should handle it, too, because
HTTP_HEADER_NAME may match an empty string:

type HTTP_HEADER_NAME = RE/|([^: \t]+:)/;
type HTTP_Header = record {
        name: HTTP_HEADER_NAME &transient;
        : HTTP_WS;
        value: bytestring &restofdata &transient;
} &oneline;

Could you please verify that the above snippet is the same in your Bro
tree? If so, could you send me a trace snippet for me to debug it?

Thanks!
Ruoming