[squid-users] urgent: bad requests; reason unknown.

From: sviau <[email protected]>
Date: Fri, 26 Mar 2004 08:52:37 -0500

were encountering some issue with our site http://www.mls.ca behind a squid
proxy. Some users (certain browsers or firewalls/proxies) are reporting bad
requests coming from our servers, on certain pages of our site ex:
http://www.mls.ca/PropertySearch.aspx (this page sets a cookie and does
redirect)

but when accessing our site on test server http://test.mls.ca, which is not
behing a squid proxy, then no problems occur for the same
users/configurations.

our IIS serb server is serving http 1.1; but squid is downgrading to http
1.0

I suspect that squid is modifiying the header sent back from the IIS web
servers behind it....

any ideas? help.

errors reported:

ERROR

The requested URL could not be retrieved

While trying to process the request:

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword,
application/x-shockwave-flash, */*

Referer: http://www.mls.ca/map.aspx?AreaID=6368

Accept-Language: en-us

Content-Type: application/x-www-form-urlencoded

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; DigExt;
Rogers Hi-Speed Internet; (R1 1.3); .NET CLR 1.0.3705)

Host: www.mls.ca

Content-Length: 281

Connection: Keep-Alive

Cache-Control: no-cache

Cookie: LegalDisclaimer=1;
SavedSearch1632138303306190944=rlt=&cp=&pt=76&mp=200000-250000-0&mrt=-1-0-0&
Beds=3-0&Baths=2-0&f=1,2&ft=all&o=A&of=1&ps=10&aid=6248&type=SavedSearch&SSN
ame=1;
SavedSearch2632143762114778750=rlt=&cp=&pt=70&mp=0-0-0&mrt=800-1200-0&Beds=1
-0&Baths=1-0&f=1,2,3&ft=all&o=A&of=1&ps=50&aid=3347,3348,3350,3351,3352,3353
,3354,3355,3356,3357&type=SavedSearch&SSName=2

__EVENTTARGET=&__EVENTARGUMENT=&__VIEWSTATE=dDwxNzAwOTQzODU2Ozs%2B&xrootHead
er%3ASideNav%3A0%3AtxtKeywords=Community&xrootHeader%3ASideNav%3A1%3Amlsnmbr
=MLS%C2%AE&Map%3AeImageMapLegend%3AMapLegend=3355&Map%3AeImageMapLegend%3AMa
pLegend=3357&Map%3AeImageMapLegend%3AbtnSearch=Search

The following error was encountered:

Invalid Request

Some aspect of the HTTP Request is invalid. Possible problems:

Missing or unknown request method

Missing URL

Missing HTTP Identifier (HTTP/1.0)

Request is too large

Content-Length missing for POST or PUT requests

Illegal character in hostname; underscores are not allowed

Your cache administrator is webmaster@mls.ca <mailto:webmaster@mls.ca>.

Generated Mon, 15 Mar 2004 02:19:48 GMT by www.mls.ca (Squid/2.4.STABLE6)

AND

http-proxy[] [x.x.x.x:1091 x.x.x.x:80] Request denied: No URI found
This message indicates a connection to a Web server was not compliant with
RFC 2068. The problem is not with the code of the Web page but with the
server itself. Web servers create headers when sending packets to clients.
These headers contain information about the page, including information the
HTTP Proxy requires to process the traffic. Part of this is a URI (Uniform
Resource Identifier). According to RFC 2068:

Uniform Resource Identifiers, (URIs) have been known by many names: WWW
addresses, Universal Document Identifiers, Universal Resource Identifiers,
and finally the combination of Uniform Resource Locators (URL) and Names
(URN). As far as HTTP is concerned, Uniform Resource Identifiers are simply
formatted strings which identify--via name, location, or any other
characteristic--a resource.

RFC 2068 defines the syntax for a URI. ''URI not found'' means either the
URI was not defined or it was defined incorrectly. By default, HTTP Proxy
blocks pages with non-compliant URIs. Solutions for this problem include:

Contacting the Web server admin to request an update to make their server
RFC 2068-compliant
Creating a Filtered-HTTP service for that site
http-proxy[] [x.x.x.x:1091 x.x.x.x:80] removing bogus HTTP header '?
HTTP\1.0'
Most browsers are lax about requiring precise HTTP header syntax. If the
Firebox HTTP Proxy encounters HTTP headers either with incorrect syntax or
not defined per RFC 2068, it strips them during transfer. The rest of the
document still transfers.

Thanks,

Stephane Viau

Systems Analyst

The Canadian Real Estate Association

sviau@crea.ca
Received on Fri Mar 26 2004 - 06:54:38 MST

This archive was generated by hypermail pre-2.1.9 : Thu Apr 01 2004 - 12:00:03 MST