Mailing List Archive

More ErrorDocument problems
This came up in trying to set up 0.6.1 on HotWired, the first time
ErrorDocument was being used to return a 401.html.

Normal 401 response looks like:

fully [185] telnet hard.wired.com 80
Trying 204.62.131.2...
Connected to hard.wired.com.
Escape character is '^]'.
GET /Login/ HTTP/1.0

HTTP/1.0 401 Unauthorized
Date: Thu, 20 Apr 1995 00:28:19 GMT
Server: Apache/0.4
Content-type: text/html
WWW-Authenticate: Basic realm="HotWired!"

<HEAD><TITLE>HotWired Authentication Failed</TITLE></HEAD>.....



However 0.6.1 is acting like this:

fully 2# telnet fully 9999
Trying 204.62.132.11...
Connected to fully.
Escape character is '^]'.
GET /Login/ HTTP/1.0

HTTP/1.0 401 Authorization Required
Date: Thu, 20 Apr 1995 00:26:14 GMT
Server: Apache/0.6.1
Content-type: text/html

<HEAD><TITLE>HotWired Authentication Failed</TITLE></HEAD>.....




Netscape is able to handle this fine - XMosaic and others aren't, which
meant we saw a lot of 401's when this was installed. I don't know if it's
the "Unauthorized" vs. "Authorization Required" that's causing problems,
or the fact there's a "Content-type: text/html" in the latte's response.
Roy would know, but I know he's in conference hell (saw him for about 5
seconds this morning before my speech at WebWorld.)

Until this is fixed the server can't be run on HotWired.

Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: More ErrorDocument problems [ In reply to ]
On Wed, 19 Apr 1995, Brian Behlendorf wrote:
> Netscape is able to handle this fine - XMosaic and others aren't, which
> meant we saw a lot of 401's when this was installed. I don't know if it's
> the "Unauthorized" vs. "Authorization Required" that's causing problems,
> or the fact there's a "Content-type: text/html" in the latte's response.
> Roy would know, but I know he's in conference hell (saw him for about 5
> seconds this morning before my speech at WebWorld.)

Or, more realistically, maybe it's the lack of

WWW-Authenticate: Basic realm="HotWired!"

in the ErrorDocument response....

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: More ErrorDocument problems [ In reply to ]
On Wed, 19 Apr 1995, Rob Hartill wrote:
> > Or, more realistically, maybe it's the lack of
> >
> > WWW-Authenticate: Basic realm="HotWired!"
> >
> > in the ErrorDocument response....
>
> maybe we need to go back to what we had - if you hit a problem/error
> and redirect to X, then you rely on X being configured to push out the
> right response.
>
> This would mean that 401 couldn't *ever* be redirected to 401.html,
> but it could redirect to 401.asis
>
> I'd be happier with this approach. The special case of a 401 -> .html
> is kinda unnatural anyway.

I hate playing the role of Crochety Old Man (particularly since I'm a
lot younger than most of you) but let's walk through what I
thought the algorithm for redirecting would have been like:

Request comes in
Response has error code X
Error code X is redirected to URI foo

Do any content-negotiation mapping necessary on URI
If URI foo is a script:
execute script and rely on script to generate headers
send to client
log access
exit
Else If URI is a .asis page
dump to client
log access
exit
Else
print headers of original response to client
print the appropriate Content-type: header
print a blank line
print data in file
log access
exit



By this logic, if the redirect is not to a CGI script or a .asis, there
should be no difference in the *headers* of a 401 response from NCSA 1.3 and
Apache (using ErrorDocument on a 401), except the latter will probably
have a Content-type: line.

Thus, I don't see why we should force ErrorDocument to point
to asis scripts.

Is the logic in the code different, modulo implementation details?

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: More ErrorDocument problems [ In reply to ]
> On Wed, 19 Apr 1995, Brian Behlendorf wrote:
> > Netscape is able to handle this fine - XMosaic and others aren't, which
> > meant we saw a lot of 401's when this was installed. I don't know if it's
> > the "Unauthorized" vs. "Authorization Required" that's causing problems,
> > or the fact there's a "Content-type: text/html" in the latte's response.
> > Roy would know, but I know he's in conference hell (saw him for about 5
> > seconds this morning before my speech at WebWorld.)
>
> Or, more realistically, maybe it's the lack of
>
> WWW-Authenticate: Basic realm="HotWired!"
>
> in the ErrorDocument response....

maybe we need to go back to what we had - if you hit a problem/error
and redirect to X, then you rely on X being configured to push out the
right response.

This would mean that 401 couldn't *ever* be redirected to 401.html,
but it could redirect to 401.asis

I'd be happier with this approach. The special case of a 401 -> .html
is kinda unnatural anyway.

robh
Re: More ErrorDocument problems [ In reply to ]
> maybe we need to go back to what we had - if you hit a problem/error
> and redirect to X, then you rely on X being configured to push out the
> right response.

slight snag..

how does the redirect pass on the authentication realm info ?

I think we need a REDIRECT_REASON cgi-variable to make this work,
and then restrict 401's to redirect only to a URL which can generate
a sensible HTTP header. i.e. a CGI script.

It'd be easier to patch the existing setup to remember the realm
info and forward that for a 401, but that'd mean sticking with the
existing concept of a 401 being treated as a special case.

So, what'll it be ?


robh
Re: More ErrorDocument problems [ In reply to ]
Last time, Brian Behlendorf uttered the following other thing:
>
> Request comes in
> Response has error code X
> Error code X is redirected to URI foo
>
> Do any content-negotiation mapping necessary on URI
> If URI foo is a script:
> execute script and rely on script to generate headers
> send to client
> log access
> exit
> Else If URI is a .asis page
> dump to client
> log access
> exit
> Else
> print headers of original response to client
> print the appropriate Content-type: header
> print a blank line
> print data in file
> log access
> exit
>
>
>
> By this logic, if the redirect is not to a CGI script or a .asis, there
> should be no difference in the *headers* of a 401 response from NCSA 1.3 and
> Apache (using ErrorDocument on a 401), except the latter will probably
> have a Content-type: line.
>
> Is the logic in the code different, modulo implementation details?

The problem we have here, is that Rob's logic is not our logic :)
Well, that and writing the server as the standard developed (came about)

The only headers set logically by dump_default_header in http_mime.c
(should we move it now that we KNOW its not mime compliant :)
is the Date and Server (or Annotations-cgi, for 1.4). Logically,
all the variables should be set before that point, and if set, should
be included when dump_default_header is called.

But, its not. Maybe I'll fix that in NCSA for 1.5, but I think Beth might
kill me for making a major modification like that at this late date . . .

Brandon

--
Brandon Long (N9WUC) "I think, therefore, I am confused." -- RAW
Computer Engineering Run Linux 1.1.xxx It's that Easy.
University of Illinois blong@uiuc.edu http://www.uiuc.edu/ph/www/blong
Don't worry, these aren't even my views.
Re: More ErrorDocument problems [ In reply to ]
On Wed, 19 Apr 1995, Rob Hartill wrote:
> > It'd be easier to patch the existing setup to remember the realm
> > info and forward that for a 401, but that'd mean sticking with the
> > existing concept of a 401 being treated as a special case.
> >
> > So, what'll it be ?
>
> patch B80 takes the easier "special case" approach.
>
> Brian, you should be able to use that right now.

Almost. It correctly gets Mosaic and Lynx to prompt for a password, but
now if you say "no" after misauthenticating yourself there's no data.
Anyone want to look at the HTTP spec
<URL:http://www.ics.uci.edu/pub/ietf/http/> and see who's breaking what?

Regardless, it's working fine in every other function so it's up on
HotWired tonight. I'll be back in the morning...

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: More ErrorDocument problems [ In reply to ]
> It'd be easier to patch the existing setup to remember the realm
> info and forward that for a 401, but that'd mean sticking with the
> existing concept of a 401 being treated as a special case.
>
> So, what'll it be ?

patch B80 takes the easier "special case" approach.

Brian, you should be able to use that right now.


n.b. I upped B79 too. It's a fix to send .asis files with their
HTTP headers stripped for assbackwards requests.



robh
Re: More ErrorDocument problems [ In reply to ]
> patch B80 takes the easier "special case" approach.

I just made it fix the "200" logging too (logs 401 now)
Re: More ErrorDocument problems [ In reply to ]
> I hate playing the role of Crochety Old Man (particularly since I'm a
> lot younger than most of you)

.. but it suits you so well ;-)
Re: More ErrorDocument problems [ In reply to ]
From: Rob Hartill <hartill@ooo.lanl.gov>
Date: Wed, 19 Apr 95 19:37:37 MDT

> maybe we need to go back to what we had - if you hit a problem/error
> and redirect to X, then you rely on X being configured to push out the
> right response.

slight snag..

how does the redirect pass on the authentication realm info ?

I think we need a REDIRECT_REASON cgi-variable to make this work,
and then restrict 401's to redirect only to a URL which can generate
a sensible HTTP header. i.e. a CGI script.

It'd be easier to patch the existing setup to remember the realm
info and forward that for a 401, but that'd mean sticking with the
existing concept of a 401 being treated as a special case.

Well, the special-case code has to go someplace --- either in the
server itself, or in every 401 handler written by anybody (which
means, in effect, that you can't write a 401 handler without CGI
overhead, and without being a protocol weenie).

Given these two unpleasant choices, my clear preference is to put it
in the server.

rst