Netscape 6.0 incompatible with older servers like NCSA httpd?

Netscape 6.0 incompatible with older servers like NCSA httpd?

Post by Prentiss Ridd » Sun, 17 Dec 2000 01:51:02



I just installed Netscape 6.0 on a Windows 2000 box and it's doing
something very strange.  When it retrieves a document or image from an
old NCSA httpd server, it displays the HTTP header along with the
content.  In the case of HTML documents this is annoying, but for
images it's disastrous, since the HTTP header info looks like garbage
to the GIF or JPG renderer.

I've looked at the Netscape 6.0 release notes
(http://home.netscape.com/eng/mozilla/ns6/relnotes/6.0.html) and I
don't see anything about this.  Is it a known bug?  Or is it a
"feature" -- has Netscape decided unilaterally to require some aspect of
HTTP 1.1 which older servers like NCSA httpd don't implement properly?

Gory details:

Here's a specific example.  My personal home page is on an NCSA httpd
1.5.1 server which we haven't gotten around to upgrading to Apache.
The page http://is.rice.edu/~riddle/tmp/ gets displayed as:

    HTTP 200 Document follows Date: Thu, 14 Dec 2000 23:28:59 GMT Server:
    NCSA/1.5.1 Last-modified: Mon, 09 Oct 2000 15:16:19 GMT Content-type:
    text/html Content-length: 5210

                                  Prentiss Riddle


    ...

The image http://is.rice.edu/~riddle/images/riddle.jpg doesn't display
at all because the HTTP header info gives the browser indigestion.  If
I use Netscape 6.0 to save the image to disk, here's what "od -c" sees
inside the file:

    0000000   H   T   T   P       2   0   0       D   o   c   u   m   e   n
    0000020   t       f   o   l   l   o   w   s  \r  \n   D   a   t   e   :
    0000040       T   h   u   ,       1   4       D   e   c       2   0   0
    0000060   0       2   3   :   2   1   :   4   0       G   M   T  \r  \n
    0000100   S   e   r   v   e   r   :       N   C   S   A   /   1   .   5
    0000120   .   1  \r  \n   L   a   s   t   -   m   o   d   i   f   i   e
    0000140   d   :       W   e   d   ,       2   3       A   p   r       1
    0000160   9   9   7       1   7   :   1   3   :   2   3       G   M   T
    0000200  \r  \n   C   o   n   t   e   n   t   -   t   y   p   e   :
    0000220   i   m   a   g   e   /   j   p   e   g  \r  \n   C   o   n   t
    0000240   e   n   t   -   l   e   n   g   t   h   :       2   6   2   1
    0000260   8  \r  \n  \r  \n 377 330 377 340  \0 020   J   F   I   F  \0
    0000300 001 002 001  \0   H  \0   H  \0  \0 377 355 001 270   P   h   o
    0000320   t   o   s   h   o   p       3   .   0  \0   8   B   I   M 003
    0000340 351  \0  \0  \0  \0  \0   x  \0 003  \0  \0  \0   H  \0   P  \0
    ...

Anybody else seen this behavior?  Must we toss out all old NCSA servers
to be compatible with Netscape 6.0?


-- Webmaster, Rice University | http://is.rice.edu/~riddle | 281-924-3630
-- Opinions expressed are not necessarily those of my employer.

 
 
 

Netscape 6.0 incompatible with older servers like NCSA httpd?

Post by Richard Cardon » Sun, 17 Dec 2000 11:04:37



> I just installed Netscape 6.0 on a Windows 2000 box and it's doing
> something very strange.  When it retrieves a document or image from an
> old NCSA httpd server, it displays the HTTP header along with the
> content.  In the case of HTML documents this is annoying, but for
> images it's disastrous, since the HTTP header info looks like garbage
> to the GIF or JPG renderer.

Prentiss,

I visited this link with Netscape 4.76, 6.0 and IE 5.5 on Win98

http://is.rice.edu/~riddle/tmp/riddle.html

They all show this header:
HTTP 200 Document follows Date: Thu, 14 Dec 2000 23:28:59 GMT Server: NCSA/1.5.1 Last-modified: Mon, 09 Oct 2000 15:16:19 GMT Content-type: text/html Content-length: 5210
Prentiss Riddle

So then I used telnet to make an HTTP/1.0 request and your server is *definitely sending two copies of the headers:

HTTP/1.0 200 Document follows
Date: Sat, 16 Dec 2000 02:01:36 GMT
Server: NCSA/1.5.1
Last-modified: Fri, 15 Dec 2000 16:19:30 GMT
Content-type: text/html
Content-length: 5389

HTTP 200 Document follows
Date: Thu, 14 Dec 2000 23:28:59 GMT
Server: NCSA/1.5.1
Last-modified: Mon, 09 Oct 2000 15:16:19 GMT
Content-type: text/html
Content-length: 5210

<HTML>
      <HEAD>
            <TITLE>Prentiss Riddle's personal web page</TITLE>

The problem is on your end not with the browsers.

Richard

 
 
 

Netscape 6.0 incompatible with older servers like NCSA httpd?

Post by Prentiss Ridd » Sun, 17 Dec 2000 12:29:39


:
: I visited this link with Netscape 4.76, 6.0 and IE 5.5 on Win98
:
: http://is.rice.edu/~riddle/tmp/riddle.html
...
: So then I used telnet to make an HTTP/1.0 request and your server is
: *definitely sending two copies of the headers...

Sorry, I cited the wrong URL.  That one is the result of a "Save As"
from the bad Netscape 6.0 on my W2K box, and so has an extra header *in
the file*.  The actual test page I meant to cite is:

        http://is.rice.edu/~riddle/

Please try that and let me know if you still see the double header.
(Actually, if you don't see the double header, it will mean that the
problem is limited to Netscape 6.0 under W2K and/or my install, not
Netscape 6.0 in general.)

Thanks.


 
 
 

Netscape 6.0 incompatible with older servers like NCSA httpd?

Post by David Efflan » Sun, 17 Dec 2000 22:26:12




>:
>: I visited this link with Netscape 4.76, 6.0 and IE 5.5 on Win98
>:
>: http://is.rice.edu/~riddle/tmp/riddle.html
>...
>: So then I used telnet to make an HTTP/1.0 request and your server is
>: *definitely sending two copies of the headers...

>Sorry, I cited the wrong URL.  That one is the result of a "Save As"
>from the bad Netscape 6.0 on my W2K box, and so has an extra header *in
>the file*.  The actual test page I meant to cite is:

>    http://is.rice.edu/~riddle/

>Please try that and let me know if you still see the double header.
>(Actually, if you don't see the double header, it will mean that the
>problem is limited to Netscape 6.0 under W2K and/or my install, not
>Netscape 6.0 in general.)

This URL just returns a single header:

HTTP/1.0 200 Document follows
Date: Sat, 16 Dec 2000 13:13:06 GMT
Server: NCSA/1.5.1
Last-modified: Mon, 09 Oct 2000 15:16:19 GMT
Content-type: text/html
Content-length: 5210

The "Document follows" string is unusual, but I would think that Netscape
should only pay attention to the "HTTP/1.0 200" which means everything is
OK, and ignore any text that follows on that line.  I do not see any
header in Netscape 4.7 (Linux), the page and images load fine.

--

http://www.autox.chicago.il.us/  http://www.berniesfloral.net/
http://cgi-help.virtualave.net/  http://hammer.prohosting.com/~cgi-wiz/

 
 
 

Netscape 6.0 incompatible with older servers like NCSA httpd?

Post by Richard Cardon » Mon, 18 Dec 2000 03:34:13



> >Sorry, I cited the wrong URL.  That one is the result of a "Save As"
> >from the bad Netscape 6.0 on my W2K box, and so has an extra header *in
> >the file*.  The actual test page I meant to cite is:

> >       http://is.rice.edu/~riddle/

> >Please try that and let me know if you still see the double header.
> >(Actually, if you don't see the double header, it will mean that the
> >problem is limited to Netscape 6.0 under W2K and/or my install, not
> >Netscape 6.0 in general.)

> This URL just returns a single header:

> HTTP/1.0 200 Document follows
> Date: Sat, 16 Dec 2000 13:13:06 GMT
> Server: NCSA/1.5.1
> Last-modified: Mon, 09 Oct 2000 15:16:19 GMT
> Content-type: text/html
> Content-length: 5210

> The "Document follows" string is unusual, but I would think that Netscape
> should only pay attention to the "HTTP/1.0 200" which means everything is
> OK,

David and Prentiss,

I see the problem now. With your revised URL, I did another telnet connection test and I received this response:

HTTP/1.0 200 Document follows
Date: Sat, 16 Dec 2000 18:19:28 GMT
Server: NCSA/1.5.1
Last-modified: Mon, 09 Oct 2000 15:16:19 GMT
Content-type: text/html
Content-length: 5210

<HTML>
      <HEAD>
            <TITLE>Prentiss Riddle's personal web page</TITLE>

Which *appears* normal, but the "blank" separation between the headers and the body is not the normal <cr><lf><cr><lf>, it's actually:
Content-length: 5210<cr><lf>
<space><cr><lf>
<HTML>...

As an http proxy developer, I used to debate whether white space in the headers is a termination or not.  IMO, it's a violation of the HTTP protocol to have all white-space header that is not just <cr><lf>.  But ultimately, I ended up coding up my proxy to accept while (length != 0 & isspace()) then treat this is a separator.  Netscape 6.0 apparently doesn't do this, but NS 4.76 and IE 5.5 do.

It's an intepretation of the HTTP specification and likely a bug in the NSCA/1.5.1 server.

Richard

 
 
 

Netscape 6.0 incompatible with older servers like NCSA httpd?

Post by Richard Cardon » Mon, 18 Dec 2000 03:34:05



> >Sorry, I cited the wrong URL.  That one is the result of a "Save As"
> >from the bad Netscape 6.0 on my W2K box, and so has an extra header *in
> >the file*.  The actual test page I meant to cite is:

> >       http://is.rice.edu/~riddle/

> >Please try that and let me know if you still see the double header.
> >(Actually, if you don't see the double header, it will mean that the
> >problem is limited to Netscape 6.0 under W2K and/or my install, not
> >Netscape 6.0 in general.)

> This URL just returns a single header:

> HTTP/1.0 200 Document follows
> Date: Sat, 16 Dec 2000 13:13:06 GMT
> Server: NCSA/1.5.1
> Last-modified: Mon, 09 Oct 2000 15:16:19 GMT
> Content-type: text/html
> Content-length: 5210

> The "Document follows" string is unusual, but I would think that Netscape
> should only pay attention to the "HTTP/1.0 200" which means everything is
> OK,

David and Prentiss,

I see the problem now. With your revised URL, I did another telnet connection test and I received this response:

HTTP/1.0 200 Document follows
Date: Sat, 16 Dec 2000 18:19:28 GMT
Server: NCSA/1.5.1
Last-modified: Mon, 09 Oct 2000 15:16:19 GMT
Content-type: text/html
Content-length: 5210

<HTML>
      <HEAD>
            <TITLE>Prentiss Riddle's personal web page</TITLE>

Which *appears* normal, but the "blank" separation between the headers and the body is not the normal <cr><lf><cr><lf>, it's actually:
Content-length: 5210<cr><lf>
<space><cr><lf>
<HTML>...

As an http proxy developer, I used to debate whether white space in the headers is a termination or not.  IMO, it's a violation of the HTTP protocol to have all white-space header that is not just <cr><lf>.  But ultimately, I ended up coding up my proxy to accept while (length != 0 & isspace()) then treat this is a separator.  Netscape 6.0 apparently doesn't do this, but NS 4.76 and IE 5.5 do.

It's an intepretation of the HTTP specification and likely a bug in the NSCA/1.5.1 server.

Richard

 
 
 

Netscape 6.0 incompatible with older servers like NCSA httpd?

Post by Nick K » Mon, 18 Dec 2000 07:41:19




(please fix your line wrap)

Quote:> Which *appears* normal, but the "blank" separation between the headers and the body is not the normal <cr><lf><cr><lf>, it's actually:
> Content-length: 5210<cr><lf>
> <space><cr><lf>
> <HTML>...

> As an http proxy developer, I used to debate whether white space in the headers is a termination or not.

That's quite clear-cut: the lone space is a continuation line of the
previous header, which is wrapped.  If your <HTML> has leading whitespace
then it is also a continuation of the header; otherwise it is a new
header (since the headers haven't been terminated).  OTOH it is clearly
not a syntactically correct HTTP header, which leaves user agents to
do error correction.

However, there *is* a way the whole response could be valid.  That is,
if the user agent treats it as an HTTP/0.9 response, then there are no
headers, and the whole of the data seen by the browser should be rendered.
Furthermore, HTTP/1.1 requires a fully compliant agent to accept a 0.9
response.  So in fact NS6 is absolutely correct.

--
Nick Kew

Site Valet - the essential service for anyone with a Website.
Now available at <URL:http://valet.webthing.com/>

 
 
 

Netscape 6.0 incompatible with older servers like NCSA httpd?

Post by Richard Cardon » Tue, 19 Dec 2000 01:39:02





> (please fix your line wrap)

Nick,

I have kicked in line wrapping for the newsreader wrapping impaired.
I thought window/terminal wrapping was a standard 21st newsreader
feature. =)

Quote:> That's quite clear-cut: the lone space is a continuation line of the
> previous header, which is wrapped.  If your <HTML> has leading whitespace
> then it is also a continuation of the header; otherwise it is a new
> header (since the headers haven't been terminated).  OTOH it is clearly
> not a syntactically correct HTTP header, which leaves user agents to
> do error correction.

Without looking at the HTTP specification, I don't think such a creature
as a line-wrapped header exists.  If a header does not conform to:
identifier:[value]<line termination>

To me it's a malformed header subject to interpretation in the
user-agent.

Quote:> However, there *is* a way the whole response could be valid.  That is,
> if the user agent treats it as an HTTP/0.9 response, then there are no
> headers, and the whole of the data seen by the browser should be rendered.
> Furthermore, HTTP/1.1 requires a fully compliant agent to accept a 0.9
> response.  So in fact NS6 is absolutely correct.

I respectfully disagree with your idea of treating this as as an
HTTP/0.9 response.  The server, immediately on response line is
declaring the response protocol at HTTP/1.0.  And once a single, valid
HTTP 1.x header is present, the contract of interpretation changes.  The
fact that it could be a valid 0.9 response is immaterial - all HTTP/1.x
responses may be valid 0.9 responses that doesn't mean they're rendered
that way.  A minor header syntax error should not revert to you the dark
ages.

In my final opinion, Mozilla 1.0 - 4.76 and IE 2.0 - 5.5sp1 _are_ the
standard.  Any deviation of behavior by NS 6.0 must be justified
rigorously against history.

Richard

 
 
 

Netscape 6.0 incompatible with older servers like NCSA httpd?

Post by Alan J. Flavel » Tue, 19 Dec 2000 03:37:10




> > (please fix your line wrap)

> I have kicked in line wrapping for the newsreader wrapping impaired.
> I thought window/terminal wrapping was a standard 21st newsreader
> feature. =)

Translation: "Richard Cardona isn't interested in published
interworking specifications, but makes up the rules as he goes along".

And we'll see how this works out, rather soon in this very posting.

Quote:> Without looking at the HTTP specification, I don't think such a creature
> as a line-wrapped header exists.

That's right enough: without reference to a specifcation, you wouldn't
expect to find that out.

So it all falls into place.

Quote:> > However, there *is* a way the whole response could be valid.  That is,
> > if the user agent treats it as an HTTP/0.9 response,

Interesting theory, Nick.  RFC2616 section 19.6

"We would expect HTTP/1.1 clients to:" [...]  "understand any
valid response in the format of HTTP/0.9".

The scenario here would seem to be an HTTP/1.*-style request being
made to a server that supports only HTTP/0.9.

But if the content body of an HTTP/0.9 request just happened to begin
with something which matched a valid HTTP/1.x response header, you're
in a dilemma, aren't you?

It's quite a different story if the client makes an HTTP/0.9-style
request, then it expects (and I think can only legally be sent) an
HTTP/0.9-style response.

Quote:> > then there are no
> > headers, and the whole of the data seen by the browser should be rendered.

I reckon so.  But I wonder just what deviations from HTTP/1.* format
in the response would justify it being tolerated as a poor HTTP/1.*
response, and which could justify it being disqualified entirely and
the whole thing being treated as an HTTP/0.9 body.

Quote:> > Furthermore, HTTP/1.1 requires a fully compliant agent to accept a 0.9
> > response.

Now, here you're going too far, Nick.  RFC2616 section 19.6 says

 "It is beyond the scope of a protocol specification to mandate
 compliance with previous versions."

Quote:> I respectfully disagree with your idea of treating this as as an
> HTTP/0.9 response.

You've already shown us that you think it's more important to make-up
the answers than to read the formal specs, so I'm not sure if there's
any point in addressing this...

Quote:> The server, immediately on response line is
> declaring the response protocol at HTTP/1.0.

And if an HTTP/0.9 response body just happened to begin with the
character sequence

HTTP/1.1 666 you canNOT be serious!(CR)(LF)

what then?

Quote:>  And once a single, valid
> HTTP 1.x header is present, the contract of interpretation changes.

Where does the RFC say this?

Quote:> fact that it could be a valid 0.9 response is immaterial - all HTTP/1.x
> responses may be valid 0.9 responses

Right, I can agree with you at least that far.  But there's this grey
area between a valid HTTP/1.x header made up oof protocol-conforming
header fields, on the one hand; and on the other hand an HTTP/0.9
response body that just happens to look somewhat like HTTP/1.x, but
not sufficiently like it to be a correct header.

What is your authoritiative justification (I mean, citation of
RFC2616) that says that it all stands or falls by the presence of a
protocol-correct "Status-line" (RFC2616 section 6.1, just in case you
decided to check it for yourself after all):
http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1

Quote:> In my final opinion, Mozilla 1.0 - 4.76 and IE 2.0 - 5.5sp1 _are_ the
> standard.

I was afraid of something like that.

The most protocol-correct browser that I've ever had to deal with
has been Lynx.  But there are protocol libraries whose whole reason
for existence is to implement HTTP correctly, rather than just be a
part of some browser package, and I'd rather expect those to be even
more protocol-conforming.  Nick might like to know how many of those
you've been involved in implementing, eh?

If you think MSIE and HTTP have much relationship to each other, then
you're talking out the back of your (head - or some other part of the
anatomy)

Quote:> Any deviation of behavior by NS 6.0 must be justified
> rigorously against history.

The one thing we learn from the history of HTTP is the importance of
not perpetrating historical ballast.
 
 
 

Netscape 6.0 incompatible with older servers like NCSA httpd?

Post by Nick K » Tue, 19 Dec 2000 05:40:45




Quote:>> > However, there *is* a way the whole response could be valid.  That is,
>> > if the user agent treats it as an HTTP/0.9 response,

> Interesting theory, Nick.  RFC2616 section 19.6

There's an interesting example rather close to you.  When I tried the
Scottish Parliament[1], I got some dreadful mess starting with a set
of HTTP headers displayed in the browser (NS 4.something).

Now in the light of this thread, I wonder if it's a variation on
the same principle, in which some proxy between Holyrood[1] and here
has received something that is strictly HTTP-compliant only if taken
as HTTP/0.9, and helpfully upgraded it to a 1.0 response for me.

Quote:> It's quite a different story if the client makes an HTTP/0.9-style
> request, then it expects (and I think can only legally be sent) an
> HTTP/0.9-style response.

Yes, that seems to apply both in theory and practice - IME.

Quote:>> > then there are no
>> > headers, and the whole of the data seen by the browser should be rendered.

> I reckon so.  But I wonder just what deviations from HTTP/1.* format
> in the response would justify it being tolerated as a poor HTTP/1.*
> response, and which could justify it being disqualified entirely and
> the whole thing being treated as an HTTP/0.9 body.

That seems to be the issue, and I'd be inclined to allow Richard a
heuristic that fixes up that single space.

Quote:>> > Furthermore, HTTP/1.1 requires a fully compliant agent to accept a 0.9
>> > response.

> Now, here you're going too far, Nick.  RFC2616 section 19.6 says

Yes.  Treating the response as 0.9 in practice is just as much error-
compensation as the DWIM approach.

Quote:>> I respectfully disagree with your idea of treating this as as an
>> HTTP/0.9 response.

That was based on the observation that it's the only thing it could
be whilst being a strictly HTTP-compliant response.  To be strictly
correct, the browser should also present the response as text/plain
rather than /html, too.

Quote:> You've already shown us that you think it's more important to make-up
> the answers than to read the formal specs, so I'm not sure if there's
> any point in addressing this...

I think you're being unnecessarily harsh.  Posting here can be light
relief from ones work deep in the RFCs.

Quote:>> The server, immediately on response line is
>> declaring the response protocol at HTTP/1.0.

> And if an HTTP/0.9 response body just happened to begin with the
> character sequence

> HTTP/1.1 666 you canNOT be serious!(CR)(LF)

> what then?

They don't call me Old Nick for nothing ;-)  But we're into dealing
with error-correction, and you might say "ignore the rubbish and
render anything that makes sense to us".

Quote:> The most protocol-correct browser that I've ever had to deal with
> has been Lynx.  But there are protocol libraries whose whole reason
> for existence is to implement HTTP correctly, rather than just be a
> part of some browser package, and I'd rather expect those to be even
> more protocol-conforming.

Hmmm ... I've seen fairly serious deviations from the standard in
both Perl's and Java's standard HTTP libraries, to name two rather
popular ones.

Quote:> If you think MSIE and HTTP have much relationship to each other, then

Er - yes.  MSIE's behaviour amounts to HTTP/0.9 with a fairly random
selection of extensions, some of which bear broad resemblance to
HTTP/1.0 and/or 1.1.

[1] long enough ago that it may have changed.
[2] or wherever their pages are served from.

--
Nick Kew

Site Valet - the essential service for anyone with a Website.
Now available at <URL:http://valet.webthing.com/>

 
 
 

Netscape 6.0 incompatible with older servers like NCSA httpd?

Post by Alan J. Flavel » Tue, 19 Dec 2000 06:57:23


(quoting my response to Richard Cardona)

Quote:> > You've already shown us that you think it's more important to make-up
> > the answers than to read the formal specs, so I'm not sure if there's
> > any point in addressing this...

> I think you're being unnecessarily harsh.

The hon usenaut had already regaled us with (and I had quoted)

| Without looking at the HTTP specification, I don't think such a creature
| as a line-wrapped header exists.

as well as the gormless banter about newsreader line length
requirements, so I thought it was a measured response in the
circumstances.

Quote:> Posting here can be light
> relief from ones work deep in the RFCs.

Indeed.  But the hon usenaut didn't seem to have bothered to look,
and even had the gall to tell us so.

Quote:> They don't call me Old Nick for nothing ;-)  But we're into dealing
> with error-correction,

Yes, I think that's the key feature here, indeed.  Sometimes (e.g as
in parts of CSS) there are protocol-correct ways of dealing with
errors (e.g the client is mandated to disregard the whole construct -
something which seems to be anathema in the house of M$).  But here
there is no "protocol correct" way of dealing with errors: clients are
urged to do their best, but, except for a very few specific points,
there is no defined "best" for them to aim at.

cheers

 
 
 

Netscape 6.0 incompatible with older servers like NCSA httpd?

Post by Richard Cardon » Tue, 19 Dec 2000 11:56:51




> (quoting my response to Richard Cardona)

> > > You've already shown us that you think it's more important to make-up
> > > the answers than to read the formal specs, so I'm not sure if there's
> > > any point in addressing this...

> > I think you're being unnecessarily harsh.

> The hon usenaut had already regaled us with (and I had quoted)

> | Without looking at the HTTP specification, I don't think such a creature
> | as a line-wrapped header exists.

Alan,
I agree with Nick, honesty should not be assailed with contempt despite
my unnecessary excursion into the features of a "modern" newsreader.
It's *not* as if I stated I've never read the HTTP RFC, au contrare I
just don't make it a point to look it up at every posting opportunity.
I do reference RFCs when actually coding vs. being a lazy on a Sunday
morn.

To prove I can read them, I was WRONG about the existence of a
multi-line header.  Quoting the HTTP 1.1 RFC:

:4.2 Message Headers
:
:HTTP header fields, which include general-header (section 4.5),
request-header (section 5.3),
:response-header (section 6.2), and entity-header
:(section 7.1) fields, follow the same generic format as that given in
Section 3.1 of RFC 822
:[9]. Each header field consists of a name followed
:by a colon (":") and the field value. Field names are case-insensitive.
The field value MAY
:be preceded by any amount of LWS, though a single
:SP is preferred.
:Header fields can be extended over multiple lines by preceding each
extra line with at least
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
:one SP or HT.
^^^^^^^^^^^^^
:Applications ought to follow "common form", where one is known or
indicated, when generating
:HTTP constructs, since there might exist some implementations that fail
to accept anything
:beyond the common forms.

I consider the above a warning.

Let me address your statements and queries:

Quote:> And if an HTTP/0.9 response body just happened to begin with the
> character sequence

> HTTP/1.1 666 you canNOT be serious!(CR)(LF)

> what then?

First all, the topic at hand is the behavior of a known HTTP/1.0 server,
namely NCSA/1.5.1.  And this not based on the response from the Server
but from Prentiss's original testimony that he running NCSA 1.5.1.
Although amusing, publishing content conformant to future specifications
on a retrograde version of an HTTP/0.9 server is not meaningful in this
context.

Quote:> >  And once a single, valid
> > HTTP 1.x header is present, the contract of interpretation changes.

> Where does the RFC say this?

The client made an HTTP/1.x request, an HTTP/1.0 server is obligated to
"respond appropriately with a message in the same protocol version used
by the client."  After invalidating your scenario of a future
specification-compliant messages on a retrograde server, an HTTP 1.x
client will parse the Server response according to the major version
received in the response header.  That is the contract I'm speaking
about.

Quoting from the HTTP/1.0 specification:
   This document defines both the 0.9 and 1.0 versions of the HTTP
   protocol. Applications sending Full-Request or Full-Response
   messages, as defined by this specification, must include an HTTP-
   Version of "HTTP/1.0".

   HTTP/1.0 servers must:

      o recognize the format of the Request-Line for HTTP/0.9 and
        HTTP/1.0 requests;

      o understand any valid request in the format of HTTP/0.9 or
        HTTP/1.0;

      o respond appropriately with a message in the same protocol
        version used by the client.

   HTTP/1.0 clients must:

      o recognize the format of the Status-Line for HTTP/1.0 responses;

      o understand any valid response in the format of HTTP/0.9 or
        HTTP/1.0.

Quote:> But there are protocol libraries whose whole reason
> for existence is to implement HTTP correctly, rather than just be a
> part of some browser package, and I'd rather expect those to be even
> more protocol-conforming.  Nick might like to know how many of those
> you've been involved in implementing, eh?

While it's true that libraries and products exist to attempt to prove
their worthiness against a subjective document, most rational human
beings who delegate the dark details of HTTP transport to (heaven
fordid) a graphical user interface written by a huge corporation, care
more about the performance, appearance and "expected" behavior than
splitting hairs about the exact semantics of a particulur request and
response.

As to my body of work and contribution to HTTP development, I've
embedded several versions of libwww into automation products, worked on
a desktop HTTP proxy client/server combination AND even contributed on
an intermediate browser called MacWeb which came into existence after
Mosaic and before Netscape 1.0.

User-wise, I've used countless user agents spanning at least ten
platforms, including using Lynx regularly. =p

Quote:> The one thing we learn from the history of HTTP is the importance of
> not perpetrating historical ballast.

I think history is against you in this regard.  If you want to treat
HTTP revolutionarily, muster your energy around HTTP-ng, HTTP/2.0 or
some other vehicle that meets your penchant for change.

sincerely with regards,
Richard

 
 
 

Netscape 6.0 incompatible with older servers like NCSA httpd?

Post by Richard Brodi » Tue, 19 Dec 2000 20:01:13



> I respectfully disagree with your idea of treating this as as an
> HTTP/0.9 response.  The server, immediately on response line is
> declaring the response protocol at HTTP/1.0.

I think I would agree with you. I don't think it would be robust
for a user agent, having received a valid HTTP response to back
up and assume 0.9 merely because it couldn't parse later headers.

However, this is not the case here. When you send a HTTP/1.1
request the status line returned is:

HTTP 200 Document follows [note no HTTP version]

This is clearly not a valid HTTP/1.0 response. This problem was
noted in the W3C reference implementation tests:
http://www.w3.org/Protocols/HTTP/Forum/Conformance.html

and subsequently fixed by NCSA in 1.5.2a.
http://hoohoo.ncsa.uiuc.edu/docs/Upgrade.html

 
 
 

Netscape 6.0 incompatible with older servers like NCSA httpd?

Post by Alan J. Flavel » Tue, 19 Dec 2000 21:34:21



> > HTTP/1.1 666 you canNOT be serious!(CR)(LF)

> > what then?

> First all, the topic at hand is the behavior of a known HTTP/1.0 server,
> namely NCSA/1.5.1.

_That_ may be your interest in the thread, indeed, but as far as an
arbitrary client is concerned, they are provided with an HTTP
connection to an as-yet-unknown server, and some protocol
specifications. They have to make up their mind about what comes back.

And that could be a protocol-conforming HTTP/1.x response, it
could be a back-level server returning an HTTP/0.9 response, or (and
this was the hypothesis that started this thread) it could be a
defective HTTP/1.x response.

Quote:> And this not based on the response from the Server
> but from Prentiss's original testimony that he running NCSA 1.5.1.

Right, but the client doesn't know that: in HTTP/0.9 they would have
no way of finding out, and in HTTP/1.x the server identification is
only informative, it's not supposed to be used as part of the
negotiation protocol.  (Sure, you _could_ use it as a way of
compensating for bugs, but that's then outside of what the protocol
specification covers).

Quote:> Although amusing, publishing content conformant to future specifications
> on a retrograde version of an HTTP/0.9 server is not meaningful in this
> context.

You're looking at it from the point of view of a well-informed
outside observer, but the client agent does not have that luxury.

Quote:> > Where does the RFC say this?

> The client made an HTTP/1.x request, an HTTP/1.0 server is obligated to
> "respond appropriately with a message in the same protocol version used
> by the client."

There's no disagreement about what the server has to do.  The argument
is about what a client can or should do when it discovers that the
response is defective.

Quote:> After invalidating your scenario of a future
> specification-compliant messages on a retrograde server,

That's an impressive piece of verbiage, but I don't know what it
means.

Quote:>    HTTP/1.0 clients must:

>       o recognize the format of the Status-Line for HTTP/1.0 responses;

Right, so I concede that part of your argument based on the status
line.  My apologies for not seeing the point earlier.

Quote:>       o understand any valid response in the format of HTTP/0.9 or
>         HTTP/1.0.

And as we've seen, these two mandates are (in the extreme case)
mutually incompatible, since an HTTP/0.9 response could be crafted to
exactly mimic an HTTP/1.x response, yet the client is expected to
handle the two cases differently.

As you have so eloquently stated, this is not the case you are
interested in.  Neverthleless, it seems to me to throw interesting
loght on the topic.  If you think otherwise, then feel free to ignore
it.

Quote:> As to my body of work and contribution to HTTP development, I've
> embedded several versions of libwww into automation products, worked on
> a desktop HTTP proxy client/server combination AND even contributed on
> an intermediate browser called MacWeb which came into existence after
> Mosaic and before Netscape 1.0.

Interesting, thanks.
 
 
 

Netscape 6.0 incompatible with older servers like NCSA httpd?

Post by Drew Laws » Thu, 21 Dec 2000 08:57:31





>>        http://is.rice.edu/~riddle/
>This URL just returns a single header:

>HTTP/1.0 200 Document follows
>Date: Sat, 16 Dec 2000 13:13:06 GMT
>Server: NCSA/1.5.1
>Last-modified: Mon, 09 Oct 2000 15:16:19 GMT
>Content-type: text/html
>Content-length: 5210

I don't know whether it makes a difference, but that is the header
only if you made a HTTP/1.0 request.  If you do it as a HTTP/1.1
request, the first line is:

    HTTP 200 Document follows

Maybe Netscape 6 doesn't know what version of HTTP to apply to this.

Is Netscape 6 still sending 1.0 requests with a Host: line, or is
it sending real 1.1 requests?

--
|Drew Lawson            |  Of all the things I've lost    |

|http://www.furrfu.com/ |                                 |

 
 
 

1. Server: NCSA Httpd Client: Netscape 3.0 Frames won't work HELP !

I'm running into a strange problem.
Just set up the NCSA httpd 1.52 server
on Solaris 2.4 for testing some stuff out.

I can't seem to get frames working with
this server and the Netscape Navigator 3.0 Gold client.
I get the code in the <NOFRAMES> block as if the browser
isn't frame enabled. But, on my other sites ( running
netscape enterprize server for example) I have no problem
with getting frames with the same client. With Internet Explhorror
it works fine.

What's the malfunction ?? :-(

2. Comaq Presario

3. W3C httpd or NCSA httpd servers on Amdahl UTS2.1

4. Java Compiler

5. NCSA HTTPD Documentation Back (hoohoo.ncsa.uiuc.edu)

6. Need general info on AIX Versions.

7. NCSA HTTPd NCSA/1.5.0a CGI question

8. MPI programs

9. Problems with NCSA 'DocFinder' under NCSA HTTPd 1.5

10. Can NCSA-HTTPD work with netscape for secure form transfer ????

11. Can NCSA httpd act as proxy for Netscape?

12. Strange error 400 between netscape 2 and ncsa httpd 1.5a...

13. NCSA httpd/Linux 2.0.x and 'httpd:cant resolve symbol recvmsg'