Re: Squid 1.2 & Error Messages

Oh, it's _doable_, but I imagine that you'd want to change the error protocol
somewhat (which means it's not comfortably backwards compatible with 1.0 and
1.1). Allow me to explain.

When squid encounters an error it sends back two pieces of information as part of
the HTTP result: An error code, and an associated text message:

HTTP/1.0 400 Cache Detected Error
(This came from 'Connection refused')

or
HTTP/1.0 400 Cache Detected Error
(This came from 'No route to host')

or
HTTP/1.0 400 Cache Detected Error
(This came from 'Connection timed out')

So, the information returned in the HTTP part of the response isn't very helpful.
You know _a_ proxy server had a problem, but you don't have any clue as to what,
and no idea _where_. You _could_ modify squid 1.2 (since it is still in the
development stage) to return special header fields giving the type of error, and
some relevant information (like who generated it). But this would be fairly
pointless to those of us with squid 1.1 or 1.0 servers further up in the
hierarchy.

But there's information there, isn't there?

Yes. It's in the HTML document returned with the error. In order to get at it,
you need to _parse_ the stupid thing. Hands up everyone who knows the mechanics
of how squid returns documents fetched from further up in the hierarchy to the
client, and thinks it's an easy thing to add content-parsing to cover all the
different types of generated error-texts (oh, and yes, the error_text adds a
message to it all, if the administrator so desires. Fortunately that's down the
bottom).

So, the steps would be:
1) Determine that it is an error message.
2) Determine that it is a _squid_ generated error message
3) Somehow get at the _content_ portion, and try to extract:
    a) The name of the server.
    b) The URL that was requested
    c) The nature of the error
4) Find an appropriate 1.2 error-text file, and output it _instead_ of the
delivered error-content, plugging in the values we got from step 3.

Yes. It _can_ be done. It may even be desirable (Honestly, I wouldn't mind having
something like it...But only so long as it was _faultless_ otherwise we confuse
the end-user and generate support calls. Gosh. We know how much fun _they_ are,
don't we? Especially when we're talking about proxies, which the end-user usually
has about the same understanding of as the average Thai curry has of the
preparation of bread-and-butter pudding. [ That is not necessarily their
fault...but it's not necessarily ours, either. They lack the foundation concepts
of internet protocols to have proxies make sense])

I heartily await a bout of spontaneous volunteering to write the code. :)

D

Michael Samuel wrote:

> On Tue, 10 Feb 1998, Alex Rousskov wrote:
>
> [ snip ]
>
> > I agree 50%. Caching proxies are _proxies_. That is, their behavior must be
> > transparent to the end user. Custom error messages (including, but not
> > limited to!, language translations) are there to achieve this transparency.
> >
> > Ideally, Squid could recognize error messages from other Squid proxies and
> > interpret them _iff_ cache admin enables such a behavior.
>
> Doesn't squid pass on http error codes?
>
> I suppose not all errors are covered by http error codes, but what's wrong
> with inventing some?
>
> [ snip ]
>
> Michael Samuel,
>
> Surf-Net City - Internet Cafe and Internet Service Providers
> Phone: +61 3 9593-9977
> E-Mail: <michael@surfnetcity.com.au>
> WWW: http://www.surfnetcity.com.au/~michael/

--
Did you read the documentation AND the FAQ?
If not, I'll probably still answer your question, but my patience will
be limited, and you take the risk of sarcasm and ridicule.