Folding Forum

THANK YOU VERY MUCH tear!

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

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.)

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: Since I'm not on his uni's payroll -- I couldn't care less.


tear

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.

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

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

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.

Dirty hands

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

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.

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): 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

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

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...

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)

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

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!