SQUID Proxy problems with assign.stanford.edu

314159 · Post by **314159** » Sun Aug 09, 2009 5:30 pm

THANK YOU VERY MUCH tear!

Let's hope that this works.
We all appreciate your expertise and persistence in dealing with this problem!!

Post by **bruce** » Mon Aug 10, 2009 8:17 am

You guys know a lot more about this than I do, but I'd like to see if we can help the NEXT guy that runs into a similar problem.

First, get somebody who actually has hands on capability give us a packet dump of the data that SQUID is rejecting. The best way to fix a problem is to actually know what's being rejected.

Second, I suspect that SQUID might be wrong. Can't some data be legally sent without any header whatsoever? As long as the message is interpreted properly by the client why does SQUID insist that there even be a header at all? (I"m sure that somebody can quote the document that answers my question.)

tear · Post by **tear** » Mon Aug 10, 2009 8:52 am

Oh sure, RFC2616.

Typically both request and response contain so-called headers
carrying additional information. You are most welcome to determine
whether set of headers sent by assign.stanford.edu is valid (per
spec).

Most likely SanHolo's uni squid is overzealous -- manual sending
his headers results in nothing unusual:

Code: Select all

jackal 02:54 [1004]:~$ telnet assign.stanford.edu 80
Trying 171.67.108.200...
Connected to assign.stanford.edu.
Escape character is '^]'.
GET / HTTP/1.1
Host: assign.stanford.edu
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us) AppleWebKit/530.19.2 (KHTML, like Gecko) Version/4.0.2 Safari/530.19
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: keep-alive

HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: no-cache
Transfer-Encoding: chunked

17
<html><b>OK</b></html>

0

Connection closed by foreign host.
jackal 02:54 [1005]:~$

Since I'm not on his uni's payroll -- I couldn't care less.

tear

Post by **bruce** » Mon Aug 10, 2009 9:00 am

You didn't answer my question.

Something that happens "Typically ...." isn't the same as something that is REQUIRED, and unless the RFC says it's required, then SQUID might be imposing unnecessary requirements. Without knowing what is being rejected, it's impossible to say what's wrong -- which is why I asked for the information on the specific packet(s) being rejected.

For the time being, I'm going to assume that there's at least one packet with no header at all. Unless the RFC says that's disallowed, you can't call that an invalid header.

tear · Post by **tear** » Mon Aug 10, 2009 9:01 am

Dear Bruce,

My intent was not to answer your question. My intent was to encourage you to get your hands dirty

Less words, more action. Thank you.

tear

tear · Post by **tear** » Mon Aug 10, 2009 9:03 am

Dear Bruce,

For the time being, I'm going to assume that there's at least one packet with no header at all. Unless the RFC says that's disallowed, you can't call that an invalid header.

Your assumption is false.

Response from assign.stanford.edu does contain headers:

HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: no-cache
Transfer-Encoding: chunked
(...)

tear

Post by **bruce** » Mon Aug 10, 2009 9:20 am

tear wrote:Your assumption is false.

Response from assign.stanford.edu does contain headers

OK, the response contains VALID headers so we still need somebody to tell us what SQUID is rejecting and why.

MtM · Post by **MtM** » Mon Aug 10, 2009 10:34 am

Dirty hands

Anyway, http://www.squid-cache.org/Doc/config/i ... xpect_100/ that looks relevant doesn't it?

314159 · Post by **314159** » Mon Aug 10, 2009 1:34 pm

I note that our friend SanHolo successfully submitted 4 SMP WUs (somehow) yesterday.

It may be that this sticky situation has been resolved and that much has been learned through it due to the assistance of those above (exclude me).

I suspect that we might be running into similar problems in the future, so let's file this thread away very gently.

THANK YOU ALL FOR YOUR HELP!

Hopefully, SanHolo will give us an update.

tear · Post by **tear** » Mon Aug 10, 2009 4:08 pm

MtM wrote:Dirty hands

<nods>

MtM wrote:Anyway, http://www.squid-cache.org/Doc/config/i ... xpect_100/ that looks relevant doesn't it?

This is unfortunately unlikely as "100 Continue" logic does not seem to be used here.

Hints from ircache.net *might* be relevant...

There are several possibilities here:
a) expected headers missing
b) excessive headers
c) malformed (or not appropriate in given context) response (in general)

Naturally, information from IT dept about actual error (perhaps from squid logs)
would be most useful

Otherwise, it's just theories (not guesses, theories) and ,,trial and error''.

Hmm, what else...
Oh yes. The request sent by browser is most likely different than request sent
by client (this might also be a factor) so operating with client request may
be more appropriate (as captured by tcpdump/wireshark or similar). It might
be, for instance, HTTP/1.0 not HTTP/1.1 request.

Now, judging by squid's output -- it's complaining about response; see
response from http://www.google.com (it's reasonable to assume google works
for SanHolo):

Code: Select all

$ telnet www.google.com 80
Trying 74.125.45.99...
Connected to www.google.com.
Escape character is '^]'.
GET / HTTP/1.1
Host: www.google.com

HTTP/1.1 200 OK
Date: Mon, 10 Aug 2009 15:29:07 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: PREF=ID=f4b46b003ec9e8eb:TM=1249918147:LM=1249918147:S=WlJx1VHAmchNTUl2; expires=Wed, 10-Aug-2011 15:29:07 GMT; path=/; domain=.google.com
Server: gws
Transfer-Encoding: chunked
(...)

As you can see, there are certain headers that google sends but stanford does not.

Server: and Set-Cookie: are obvious non-candiates.

Date: and Expires: are (IMHO).

Re Date:
Section 14.18 of RFC2616 says that for 2xx responses Date: is
a MUST except for clockless origin servers (14.18.1). Thing
is, assign.stanford.edu meets criteria of clockless origin
server.

Re Expires:
Clockless origin servers MUST NOT send Expires: (so we're
good here too)

Now, as far as trial-and-error part goes... give me 30 minutes.

tear

tear · Post by **tear** » Mon Aug 10, 2009 4:38 pm

SanHolo,

Can you please try following URLs via your uni's proxy?

http://braxis.org/testA
http://braxis.org/testB
http://braxis.org/testC

That should give us *some* answers.

Thanks,
tear

SanHolo · Post by **SanHolo** » Mon Aug 10, 2009 11:19 pm

I can check that tomorrow morning; I don't know of any other website that troubles the squid, but I assume there are a few more since the IT-dept told me they are looking for a way to subdue the few stubborn websites.

Maybe the information in my first post in this thread helps, especially the last two sentences from my ircache.net-quote:

...It doesn't have a Content-Length header present, so it can't be used in a HTTP/1.0 persistent connection. The Web server didn't send a Date header for this object, which may cause problems.

Edit:
The above quote is what I get when I enter http://assign.stanford.edu/ in http://www.ircache.net/cgi-bin/cacheability.py
However, the argument that it can't be cached (and therefore is invalid?) is somewhat odd to me since there is a no-cache pragma, anyway...

SanHolo · Post by **SanHolo** » Tue Aug 11, 2009 7:09 am

tear wrote:Can you please try following URLs via your uni's proxy?

http://braxis.org/testA
http://braxis.org/testB
http://braxis.org/testC

Just tried, and they all fail in Safari, but all deliver an OK from Firefox

. Both browsers run through the proxy. From home, only C failed (Safari). Safari tells me:

The error is: “Operation could not be completed. (kCFErrorDomainCFNetwork error 303.)”

cURL complains about:

curl: (56) Received problem 2 in the chunky parser

(Can you keep the page up for some days? Submitted a bug report to Apple regarding Safaris inability to load it)

tear · Post by **tear** » Tue Aug 11, 2009 10:34 am

SanHolo,

For the record, these are not generated by a real web server -- it's just a *dumb* test
application returning the same response no matter what headers you send in the request.

Still, browser behavioral differences are interesting...

testA reports same headers as assign.stanford.edu + Connection:
testB reports same headers as assign.stanford.edu + Connection: + Date: + Expires:
testC is a short-response (invalid) so I wouldn't worry much about it...

I'm pretty sure A and B return valid HTTP/1.1 responses.

Anyway, what's most bothering -- why the hell does anything work in the first place?
I'm starting to believe it's not the headers but the way data are sent on
TCP/socket layer.

Now... how about these two? (can you check with both browsers as well please?)
http://braxis.org/testD
http://braxis.org/testE

It appears I have lied -- more questions than answers

Thanks much,
tear

SanHolo · Post by **SanHolo** » Tue Aug 11, 2009 12:55 pm

Hey tear. Here the results:
testD fails on both (Safari and Firefox) with a message from the Proxy: Error Message. testE fails in Safari, returns OK in Firefox - same as for testA-testC.
Hope that helps.

Thanks for not giving up!

Folding Forum

SQUID Proxy problems with assign.stanford.edu

Re: SQUID Proxy problems with assign.stanford.edu

Re: SQUID Proxy problems with assign.stanford.edu

Re: SQUID Proxy problems with assign.stanford.edu

Re: SQUID Proxy problems with assign.stanford.edu

Re: SQUID Proxy problems with assign.stanford.edu

Re: SQUID Proxy problems with assign.stanford.edu

Re: SQUID Proxy problems with assign.stanford.edu

Re: SQUID Proxy problems with assign.stanford.edu

Re: SQUID Proxy problems with assign.stanford.edu

Re: SQUID Proxy problems with assign.stanford.edu

Re: SQUID Proxy problems with assign.stanford.edu

Re: SQUID Proxy problems with assign.stanford.edu

Re: SQUID Proxy problems with assign.stanford.edu

Re: SQUID Proxy problems with assign.stanford.edu

Re: SQUID Proxy problems with assign.stanford.edu