Is anybody else seeing this issue with the Symantec web site?
Has anybody contacted Symantec and/or SCUR?
Would you be willing to share the ticket # from either vendor?

I'd like to be able to reference an existing case (there should be at
least one existing SCUR case) when contacting the vendors so we can
more swiftly escalate the support case.

Thanks,

Kevin Kadow


---------- Forwarded message ----------
From: Obfuscated user
Date: Jun 15, 2006 2:59 PM
Subject: Re: [Sidewinder] Protocol error on searching www.symantec.com
To: sidewinder@adeptech

>Indeed, one would think this would cover it:
>
> A duplicate response status line is allowed in middle of
headers.
>
>Perhaps this does not include "A *different* status line at the
*beginning* of the headers".

I looked a bit closer into what the server is returning by doing a
telnet on port 80 and manually issuing the GET:

GET
http://search.symantec.com/custom/update/query.html?charset=utf-8&filter
=all&nh=10&hitsceil=100&st=1&context=gbh&qt=testing&x=17&y=6 HTTP/1.0

HTTP/1.0 302 Moved Temporarily
HTTP/1.0 200 OK
Content-type: text/html; charset=utf-8
Server: Inktomi Search 4.1.0
Date: Wed, 14 Jun 2006 17:34:10 GMT
Server: Inktomi Search 4.1.0
Date: Wed, 14 Jun 2006 17:34:10 GMT
Location:
http://searchg.symantec.com/search?q=testing&context=gbh&src=gbh&output=
xml_no_dtd&ie=UTF-8&oe=UTF-8&client=symc_en_US&proxystylesheet=symc_en_U
S&site=symc_en_US
Content-length: 0

so it is doing other things which the documentation clearly doesn't say
the "relax" would allow, such as two Date: and two Server: headers...
(Clearly, symantec could be hiring CGI programmers with more skill!)

>>>I can reproduce this. Seems to be a confused webserver at Symantec.
>>>tcpdump reveals: [...Removed...]
>>>
>>>Or more plainly:
>>>HTTP/1.0 302 Moved Temporarily
>>>HTTP/1.0 200 OK
>>>Content-type: text/html; charset=utf-8
>>>Server: Inktomi Search 4.1.0
>>>...
>>
>>Yes, I agree that the remote site is breaking the protocol.
>>
>>>You could probably relax the protocol enforcements on the Sidewinder
>>
>>I've tried that, and it is still being denied. From "man
>>cf_appfilter", the behavior change when doing this is:
>>
>>Specifically, the following protocol violations are allowed:
>> Query strings (data after the "?") in a URL are allowed to
>> contain arbitrary data.
>> Empty header names are allowed (e.g., ":value").
>> Invalid Content-Type: headers are allowed
>> (i.e., no "/" present).
>> A duplicate response status line is allowed in middle of
headers.
>> An entity is allowed in an HTTP/1.1 response with status code of
205.
>>
>>So I'd think this should correct it, but the acat output still says
>>that "Header has no delimiter".
>>
>>http://distribution.qmags.com/isapitest/isapitest.dll?sessionI
>>D=0CA51B82BEB2FCACD0C8FD1AF&editionID=11613&platform=PC
>> also exhibits the same behavior.