List of HTTP errors?
samer
that HTTP sends when an invalid request is made?
I have read through:
http://www.w3.org/Protocols/rfc2616/rfc2616.html
but that does not help me to find out what error message this request
for example produces:
GET /~ross/ HTTP/ 4.5
or:
GET /~ross/ HTTPPP/ 1.1
I have tried testing the request's through telnet but it just closes.
Is there any systematic way to know which error messages invalid
requests produce?
David Schwartz
samer wrote:
> How do I find a systematic way to know what kind of an error message
> that HTTP sends when an invalid request is made?
Yes, certainly.
> I have read through:
>
> http://www.w3.org/Protocols/rfc2616/rfc2616.html
>
> but that does not help me to find out what error message this request
> for example produces:
>
> GET /~ross/ HTTP/ 4.5
That's not HTTP.
> or:
>
> GET /~ross/ HTTPPP/ 1.1
That's not HTTP.
> I have tried testing the request's through telnet but it just closes.
> Is there any systematic way to know which error messages invalid
> requests produce?
These are not invalid requests, these are not requests. They are not
defined by the HTTP protocol. A server could do anything at all with
these requests.
For your first example, we won't know until HTTP version 4.5 comes out.
For the second, we won't know until someone creates a protocol called
HTTPPP. Nobody can predict today what those future standards will say.
DS
Barry Margolin
"David Schwartz" <dav...@webmaster.com> wrote:
> samer wrote:
>
> > How do I find a systematic way to know what kind of an error message
> > that HTTP sends when an invalid request is made?
>
> Yes, certainly.
>
> > I have read through:
> >
> > http://www.w3.org/Protocols/rfc2616/rfc2616.html
> >
> > but that does not help me to find out what error message this request
> > for example produces:
> >
> > GET /~ross/ HTTP/ 4.5
>
> That's not HTTP.
>
> > or:
> >
> > GET /~ross/ HTTPPP/ 1.1
>
> That's not HTTP.
>
> > I have tried testing the request's through telnet but it just closes.
> > Is there any systematic way to know which error messages invalid
> > requests produce?
>
> These are not invalid requests, these are not requests. They are not
> defined by the HTTP protocol. A server could do anything at all with
> these requests.
I think the point of his question is whether the HTTP spec says what a
server is supposed to do in response to requests that it doesn't
understand (in this case because they're invalid).
> For your first example, we won't know until HTTP version 4.5 comes out.
Sure we do. The question is presumably about what a 1.1 server should
do with such a request. It seems to me that "505 HTTP Version Not
Supported" is the appropriate response.
> For the second, we won't know until someone creates a protocol called
> HTTPPP. Nobody can predict today what those future standards will say.
Again, the question is about what *current* servers should do in
response to this request, not what some hypothetical server that
supports HTTPPP/1.1 might do. "400 Bad Request" seems appropriate,
doesn't it?
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
David Schwartz
Barry Margolin wrote:
> In article <1158094652....@i42g2000cwa.googlegroups.com>,
> "David Schwartz" <dav...@webmaster.com> wrote:
> > These are not invalid requests, these are not requests. They are not
> > defined by the HTTP protocol. A server could do anything at all with
> > these requests.
> I think the point of his question is whether the HTTP spec says what a
> server is supposed to do in response to requests that it doesn't
> understand (in this case because they're invalid).
It can't say. These are not HTTP requests.
> > For your first example, we won't know until HTTP version 4.5 comes out.
>
> Sure we do. The question is presumably about what a 1.1 server should
> do with such a request. It seems to me that "505 HTTP Version Not
> Supported" is the appropriate response.
If that were the correct thing to do, HTTP 1.0 servers might not work
with modern clients. (They would return 505 errors. I wonder if clients
would retry.)
I think in this case you are better off assuming that the versions will
be compatible. Just make sure you don't blindly copy the '4.5' into
your reply but state the version of the protocol you actually support.
> > For the second, we won't know until someone creates a protocol called
> > HTTPPP. Nobody can predict today what those future standards will say.
>
> Again, the question is about what *current* servers should do in
> response to this request, not what some hypothetical server that
> supports HTTPPP/1.1 might do. "400 Bad Request" seems appropriate,
> doesn't it?
It seems odd to send an HTTP reply to something that is not an HTTP
request. You can't know what '400 Bad Request' will mean in HTTPPP
version 1.1. I don't think you can really argue anything is
particularly better than anything else. You are dealing with a protocol
of which you have no comprehension at all.
I personally think it's inappropriate to send a header since you have
no way to know that the client supports headers. HTTP 0.9 clients, for
example, do not. Sending headers should be done only if that capability
is validly negotiated. (Though, of course, you can't really argue it's
a bug or anything like that.)
DS
Barry Margolin
"David Schwartz" <dav...@webmaster.com> wrote:
> Barry Margolin wrote:
>
> > In article <1158094652....@i42g2000cwa.googlegroups.com>,
> > "David Schwartz" <dav...@webmaster.com> wrote:
>
> > > These are not invalid requests, these are not requests. They are not
> > > defined by the HTTP protocol. A server could do anything at all with
> > > these requests.
>
> > I think the point of his question is whether the HTTP spec says what a
> > server is supposed to do in response to requests that it doesn't
> > understand (in this case because they're invalid).
>
> It can't say. These are not HTTP requests.
>
> > > For your first example, we won't know until HTTP version 4.5 comes out.
> >
> > Sure we do. The question is presumably about what a 1.1 server should
> > do with such a request. It seems to me that "505 HTTP Version Not
> > Supported" is the appropriate response.
>
> If that were the correct thing to do, HTTP 1.0 servers might not work
> with modern clients. (They would return 505 errors. I wonder if clients
> would retry.)
That's the difference between major and minor version numbers. Within
the same major version, the general request/reply syntax stays the same.
So a 1.0 server should be expected to understand a 1.1 request. On the
other hand, it's less likely that a 4.5 request will be meaningful to a
1.0 server -- perhaps in 4.5 the request-header field names will be in
French rather than English.
> I think in this case you are better off assuming that the versions will
> be compatible. Just make sure you don't blindly copy the '4.5' into
> your reply but state the version of the protocol you actually support.
I think it's safe within a major version. Across different major
versions, I think the 505 error would be a reasonable option. But
that's up to the server designer to decide. But *if* it doesn't accept
commands with that major version, it should send the 505 error.
> > > For the second, we won't know until someone creates a protocol called
> > > HTTPPP. Nobody can predict today what those future standards will say.
> >
> > Again, the question is about what *current* servers should do in
> > response to this request, not what some hypothetical server that
> > supports HTTPPP/1.1 might do. "400 Bad Request" seems appropriate,
> > doesn't it?
>
> It seems odd to send an HTTP reply to something that is not an HTTP
> request. You can't know what '400 Bad Request' will mean in HTTPPP
> version 1.1. I don't think you can really argue anything is
> particularly better than anything else. You are dealing with a protocol
> of which you have no comprehension at all.
You have to send back something, don't you? Since you're an HTTP
server, you send an HTTP reply, because that's all you know how to do.
And the appropriate reply is 400. If the client doesn't understand it,
that's his problem -- an HTTPPP client shouldn't connect to an HTTP
server and expect to understand the response.
Michael Wojcik
In article <1158094652....@i42g2000cwa.googlegroups.com>, "David Schwartz" <dav...@webmaster.com> writes:
> samer wrote:
>
> > but that does not help me to find out what error message this request
> > for example produces:
> >
> > GET /~ross/ HTTP/ 4.5
>
> That's not HTTP.
>
> > or:
> >
> > GET /~ross/ HTTPPP/ 1.1
>
> That's not HTTP.
>
> > I have tried testing the request's through telnet but it just closes.
> > Is there any systematic way to know which error messages invalid
> > requests produce?
>
> These are not invalid requests, these are not requests. They are not
> defined by the HTTP protocol. A server could do anything at all with
> these requests.
>
> For your first example, we won't know until HTTP version 4.5 comes out.
And not even then, unless some future HTTP specification allows LWS
between the "/" and the first digit in the HTTP-Version.
I wouldn't recommend a server send an HTTP error response for either
of these requests. They're malformed. Just closing the connection
strikes me as the appropriate behavior.
--
Michael Wojcik michael...@microfocus.com
Only the obscene machine has persisted
jerky and jockeying and not knowing why
I have never existed. Nor should. -- George Barker
Michael Wojcik
In article <barmar-2E8D64....@comcast.dca.giganews.com>, Barry Margolin <bar...@alum.mit.edu> writes:
> In article <1158094652....@i42g2000cwa.googlegroups.com>,
> "David Schwartz" <dav...@webmaster.com> wrote:
> > samer wrote:
> >
>
> > For your first example, we won't know until HTTP version 4.5 comes out.
>
> Sure we do. The question is presumably about what a 1.1 server should
> do with such a request. It seems to me that "505 HTTP Version Not
> Supported" is the appropriate response.
Had the first request been "GET /~ross/ HTTP/4.5" (without the quotes
and followed by CR LF CR LF), I could see a 505 response. As
presented, it's not HTTP; an HTTP server is under no requirement to
even parse that bogus HTTP-Version, according to the grammar in RFC
2616 3.1.
--
Michael Wojcik michael...@microfocus.com
Thus, the black lie, issuing from his base throat, becomes a boomerang to
his hand, and he is hoist by his own petard, and finds himself a marked man.
-- attributed to a "small-town newspaper editor in Wisconsin"
Ben_
> of these requests. They're malformed. Just closing the connection
> strikes me as the appropriate behavior.
Closing the connection without telling why is not informative and makes it
harder to troubleshoot...
David Schwartz
Ben_ wrote:
> > I wouldn't recommend a server send an HTTP error response for either
> > of these requests. They're malformed. Just closing the connection
> > strikes me as the appropriate behavior.
> Why is there an "HTTP 400 Bad Request" in the spec then ?
How did you establish that that was the correct specification to
follow? You're presumably a multi-protocol server, you support HTTP
0.9, HTTP 1.0, perhaps HTTP 1.1. If you're going to pick one of those
specifications to follow in the absence of proper protocol negotiation,
it should be the earliest one.
> Closing the connection without telling why is not informative and makes it
> harder to troubleshoot...
Why would you assume a client that sends such a request is "more like"
an HTTP 1.0 client than an HTTP 0.9 client? How else can you justify
sending an HTTP 1.0 error message?
When you see a "request" that's that badly malformed, you have no way
to know what the client is going to do with the reply. If it's an HTTP
0.9 client, it might misunderstand the error header as the payload and
*accept* it!
DS
David Schwartz
Barry Margolin wrote:
> > If that were the correct thing to do, HTTP 1.0 servers might not work
> > with modern clients. (They would return 505 errors. I wonder if clients
> > would retry.)
> That's the difference between major and minor version numbers. Within
> the same major version, the general request/reply syntax stays the same.
> So a 1.0 server should be expected to understand a 1.1 request. On the
> other hand, it's less likely that a 4.5 request will be meaningful to a
> 1.0 server -- perhaps in 4.5 the request-header field names will be in
> French rather than English.
I see your point, but I don't see why that same argument wouldn't apply
to reply headers as well as request headers. How can you assume the
client would understand the error message and wouldn't interpret it as
something completely different, possibly harmful?
DS
Ben_
"David Schwartz" <dav...@webmaster.com> wrote in message
news:1158175009....@h48g2000cwc.googlegroups.com...
I feel like I'm missing your point, maybe because I'm not too familiar with
HTTP/0.9, I admit.
From what I read, I don't see a problem to return HTTP 400 and I don't see
why it would be a bad behavior towards an HTTP/0.9 client (HTTP 400 was
already defined in RFC 1945).
Now my reasoning is: because in (1) there is a space between "HTTP/" and
"4.5" and because in (2) protocol is spelled "HTTPPP/", there are syntax
errors and HTTP 400 looks a logical answer to me ("400 Bad Request - The
request could not be understood by the server due to malformed syntax.").
Example (1) cannot be tried to be understood as HTTP/0.9, because in 0.9,
the protocol version is not specified, so "[space]4.5" is not an indication
of an HTTP/0.9 request.
David Schwartz
Ben_ wrote:
> I feel like I'm missing your point, maybe because I'm not too familiar with
> HTTP/0.9, I admit.
> From what I read, I don't see a problem to return HTTP 400 and I don't see
> why it would be a bad behavior towards an HTTP/0.9 client (HTTP 400 was
> already defined in RFC 1945).
An HTTP 0.9 client does not support response headers. If you sent an
HTTP error to an HTTP 0.9 client, it would think that header was a
valid response.
Connect to any Apache server and send this "GET foobar" (assuming
'foobar' does not exist). Notice that it does *not* send an error
header. Then try "MOO foobar" and you will again see that it does *not*
send an error header. This is because the client would think the error
was a valid payload.
> Now my reasoning is: because in (1) there is a space between "HTTP/" and
> "4.5" and because in (2) protocol is spelled "HTTPPP/", there are syntax
> errors and HTTP 400 looks a logical answer to me ("400 Bad Request - The
> request could not be understood by the server due to malformed syntax.").
Yes, it is a logical answer to an HTTP 1.x client. But you have no
reason to believe (and every reason not to believe) that you are
talking to an HTTP 1.x client.
> Example (1) cannot be tried to be understood as HTTP/0.9, because in 0.9,
> the protocol version is not specified, so "[space]4.5" is not an indication
> of an HTTP/0.9 request.
It is not an indication of an HTTP/1.x request either. So why would you
think an HTTP/1.x response would be valid?
DS
Barry Margolin
"David Schwartz" <dav...@webmaster.com> wrote:
In general, when protocol designers make such drastic changes that this
could happen, they also assign a new port to make it unlikely that
grossly incompatible clients and servers will talk to each other. This
allows the server to assume some basic level of interoperability with
clients that have connected to them -- the fact that the client
connected to port 80 implies that he understands the least common
denominator of HTTP 0.9, 1.0, and 1.1; if not, he shouldn't have
connected to port 80, and it's not the server's job to protect the
client from such mistakes. Didn't HTTP 0.9 have error codes roughly
similar to 1.0 and 1.1 (I assume so, since the scheme is mostly just
copied from SMTP and FTP)?
As a similar problem, tell your browser to go to URL
http://some-smtp-server:25 and do a packet capture to see what happens.
The SMTP server will receive an HTTP GET command. Of course, it won't
recognize this, so it will send a "500 Command not understood" reply
(although the browser won't process this properly, having already
received the server's "220" greeting).
David Schwartz
Barry Margolin wrote:
> In general, when protocol designers make such drastic changes that this
> could happen, they also assign a new port to make it unlikely that
> grossly incompatible clients and servers will talk to each other.
Right.
> This
> allows the server to assume some basic level of interoperability with
> clients that have connected to them -- the fact that the client
> connected to port 80 implies that he understands the least common
> denominator of HTTP 0.9, 1.0, and 1.1; if not, he shouldn't have
> connected to port 80, and it's not the server's job to protect the
> client from such mistakes.
I agree. So you should send an HTTP 0.9 style error.
> Didn't HTTP 0.9 have error codes roughly
> similar to 1.0 and 1.1 (I assume so, since the scheme is mostly just
> copied from SMTP and FTP)?
No. Check this out:
$ telnet www.apache.org 80
Trying 192.87.106.226...
Connected to www.apache.org.
Escape character is '^]'.
GET foobar
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not
understand.<br />
</p>
<hr>
<address>Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g Server at
www.apache.org Port 80</address>
</body></html>
Connection closed by foreign host.
Notice that *no* headers were sent in reply. This is because HTTP 0.9
did not support any headers. Now watch this:
$ telnet www.apache.org 80
Trying 192.87.106.226...
Connected to www.apache.org.
Escape character is '^]'.
GET foobar
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not
understand.<br />
</p>
<hr>
<address>Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g Server at
www.apache.org Port 80</address>
</body></html>
Connection closed by foreign host.
[davids@youknow pdcfg]$ telnet www.apache.org 80
Trying 192.87.106.226...
Connected to www.apache.org.
Escape character is '^]'.
MOO cow
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not
understand.<br />
</p>
<hr>
<address>Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g Server at
www.apache.org Port 80</address>
</body></html>
Connection closed by foreign host.
This is, IMO, sensible behavior.
However, Apache treats any query with three terms as implying support
for HTTP headers. I don't know how you can really argue that this is
wrong or right. There is no overarching standard to specify how a
multi-protocol server should handle a query that doesn't definitely
establish what protocol the client is using.
> As a similar problem, tell your browser to go to URL
> http://some-smtp-server:25 and do a packet capture to see what happens.
> The SMTP server will receive an HTTP GET command. Of course, it won't
> recognize this, so it will send a "500 Command not understood" reply
> (although the browser won't process this properly, having already
> received the server's "220" greeting).
Right, nothing you can do about that, until and unless someone creates
some super-standard that provides a way to say "I am an SMTP server"
and both server and client support that standard.
Arguably, it would be a good idea for all servers that can practically
do so to recognize HTTP 0.9, 1.0 and 1.1 requests and provide a
sensible error messages. You can't always do this, but you can most of
the time.
DS
Ben_
> 'foobar' does not exist). Notice that it does *not* send an error
> header. Then try "MOO foobar" and you will again see that it does *not*
> send an error header. This is because the client would think the error
> was a valid payload.
> > Example (1) cannot be tried to be understood as HTTP/0.9, because in
0.9,
> > the protocol version is not specified, so "[space]4.5" is not an
indication
> > of an HTTP/0.9 request.
>
> It is not an indication of an HTTP/1.x request either. So why would you
> think an HTTP/1.x response would be valid?
>
Looks like we come to an implementation decision and it'd be subject to a
matter of taste I suppose.
To me, as the request is not HTTP/0.9 compliant, I'd make the server reply
in the most widely supported standard at the time of implementation.
Why not behave like an HTTP/1.0 or HTTP/1.1 server, as we known it's not a
valid HTTP/0.9 request ?
Michael Wojcik
In article <45082523$0$5529$ba62...@news.skynet.be>, "Ben_" <re...@newsgroup.com> writes:
Please include proper attribution lines when you quote someone. In
this case, I wrote the twice-quoted material below.
> > I wouldn't recommend a server send an HTTP error response for either
> > of these requests. They're malformed. Just closing the connection
> > strikes me as the appropriate behavior.
> Why is there an "HTTP 400 Bad Request" in the spec then ?
This is a bad HTTP request:
WUBBLE / HTTP/1.1 CR LF CR LF
An HTTP server could respond to that with a 400. It's a well-formed
HTTP request with an illegal Method.
RFC 2616 mentions some other cases where 400 is an appropriate
Status Code:
- A request contains a message body but no mechanism for the server
to determine message length. The server can also use 411 (length
required), at its discretion. (4.4)
- The host determined from the Request-URI (if it is an absoluteURI)
or the Host header field is not a valid host for the origin server,
and the origin server differentiates resources based on the host.
In this case, the server MUST respond with a 400. (5.2)
- The request specifies HTTP/1.1 and does not contain a Host header.
"All Internet-based HTTP/1.1 servers MUST respond with a 400" in
this case. (14.23)
- The previous requirement is extended to all HTTP/1.1 servers, not
just "Internet-based" ones. (19.6.1.1. It's a pity no one noticed
this while 2616 was still a draft; they could have deleted that
ill-defined "Internet-based" nonsense from 14.23.)
> Closing the connection without telling why is not informative and makes it
> harder to troubleshoot...
There's no point in being "informative" if the client is not an HTTP
client. In that case, there's no way of knowing how the client will
interpret the response, so closing the connection is the safe,
conservative option.
Yes, if the malformed syntax is simply extra LWS, as in this case,
*we* can easily tell that the client is probably a broken HTTP client.
But we can't be sure, and it's not trivial to write a server that can
accurately distinguish when a malformed request is "probably" from a
broken HTTP client, and it's not at all clear what cases fall into
that category.
HTTP is actually quite easy to troubleshoot, as application protocols
go. It's significantly easier than, say, Telnet, and far, far easier
than, oh, any SNA protocol. I don't think we need to go out of our
way to try to make it easier - particularly at the risk of creating
complex, unpredictable, inconsistent server behaviors because we have
a mess of heuristics to try to determine what sort of incorrect
client we have.
--
Michael Wojcik michael...@microfocus.com
Maybe, but it can't compete with _SNA Formats_ for intricate plot
twists. "This format is used only when byte 5, bit 1 is set to 1
(i.e., when generalized PIU trace data is included)" - brilliant!
Michael Wojcik
In article <barmar-CBA606....@comcast.dca.giganews.com>, Barry Margolin <bar...@alum.mit.edu> writes:
>
> the fact that the client
> connected to port 80 implies that he understands the least common
> denominator of HTTP 0.9, 1.0, and 1.1; if not, he shouldn't have
> connected to port 80,
Hardly. If the client can't format an HTTP Request-Line correctly,
why should anyone assume it can choose a port correctly? Maybe it
meant to connect to port 0x5000 and incorrectly swapped the bytes.
> and it's not the server's job to protect the
> client from such mistakes.
It's not the server's job to inform the client of such mistakes,
either. Either the client and server speak the same protocol, or
they do not. If the client starts off in a foreign language, I
don't see any justification for the server to try replying in HTTP.
> As a similar problem, tell your browser to go to URL
> http://some-smtp-server:25 and do a packet capture to see what happens.
> The SMTP server will receive an HTTP GET command. Of course, it won't
> recognize this, so it will send a "500 Command not understood" reply
> (although the browser won't process this properly, having already
> received the server's "220" greeting).
The case is hardly parallel, since SMTP is a server-speaks-first
protocol. And the SMTP specification (well, RFC 2821, which is
the standards-track replacement for STD 10) mandates this behavior:
In particular, a server that closes connections in response to
commands that are not understood is in violation of this
specification. Servers are expected to be tolerant of unknown
commands, issuing a 500 reply and awaiting further instructions from
the client. (3.9)
RFC 2616 does not, which is in my opinion the better decision.
(It's not clear to me whether RFC 2821 allows the server to close
the connection for more egregious errors. It doesn't define
"unknown commands" very well, so it's not immediately apparent
whether this clause would apply to non-ASCII data sent by the
client, for example.)
--
Michael Wojcik michael...@microfocus.com
I will shoue the world one of the grate Wonders of the world in 15
months if Now man mourders me in Dors or out Dors
-- "Lord" Timothy Dexter, _A Pickle for the Knowing Ones_
Vernon Schryver
Michael Wojcik <mwo...@newsguy.com> wrote:
>The case is hardly parallel, since SMTP is a server-speaks-first
>protocol. And the SMTP specification (well, RFC 2821, which is
>the standards-track replacement for STD 10) mandates this behavior:
>
> In particular, a server that closes connections in response to
> commands that are not understood is in violation of this
> specification. Servers are expected to be tolerant of unknown
> commands, issuing a 500 reply and awaiting further instructions from
> the client. (3.9)
>
>RFC 2616 does not, which is in my opinion the better decision.
I understand that a future version of sendmail might optionally refuse
to work with an SMTP client that has started with a typical HTTP command
in order to foil the abuse of HTTP proxies to send spam.
Vernon Schryver v...@rhyolite.com
James Antill
>
> In article <1158094652....@i42g2000cwa.googlegroups.com>, "David Schwartz" <dav...@webmaster.com> writes:
>> samer wrote:
>>
>> > but that does not help me to find out what error message this request
>> > for example produces:
>> >
>> > GET /~ross/ HTTP/ 4.5
>>
>> That's not HTTP.
> And not even then, unless some future HTTP specification allows LWS
> between the "/" and the first digit in the HTTP-Version.
rfc2616 already states that:
2.1
implied *LWS
The grammar described by this specification is word-based. Except
where noted otherwise, linear white space (LWS) can be included
between any two adjacent words (token or quoted-string), and between
adjacent words and separators, without changing the interpretation of
a field. At least one delimiter (LWS and/or separators) MUST exist
between any two tokens (for the definition of "token" below), since
they would otherwise be interpreted as a single token.
3.1
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
...I fail to see how you can read that as anything other than the
HTTP-Version having 5 tokens, which can have arbitrary implied LWS between
them.
The request line is specially exempt from having CRLF TAB in the LWS
by 5.1.
Also 19.3 explicitly says:
Clients SHOULD be tolerant in parsing the Status-Line and servers
tolerant when parsing the Request-Line. In particular, they SHOULD
accept any amount of SP or HT characters between fields, even though
only a single SP is required.
--
James Antill -- ja...@and.org
http://www.and.org/and-httpd
Michael Wojcik
Interesting. It's also an example of how the Robustness Principle[1]
can have unintended security consequences. (That doesn't mean the
Robustness Principle is always wrong, just that it trades a measure
of security for interoperability. Whether that's a problem depends
on your threat model, as with any other security trade-off.)
[1] Jon Postel's dictum "Be conservative in what you do, be liberal
in what you accept from others". RFC 793 2.10.
--
Michael Wojcik michael...@microfocus.com
The guy who's fast in the mountain pass is the coolest.
-- _Initial D: Second Stage_
Michael Wojcik
Hmm. That may indeed apply, in which case this one of the OP's
examples is valid HTTP. The required behavior for a server in this
case is more complex (for example, proxies and gateways have different
requirements from origin servers), and I'm not going to attempt to
enumerate all the cases.
My comments still apply to the OP's other example, however.
> The request line is specially exempt from having CRLF TAB in the LWS
> by 5.1.
I don't see any reference to HT being prohibited in 5.1. CR and LF,
yes.
> Also 19.3 explicitly says:
>
> Clients SHOULD be tolerant in parsing the Status-Line and servers
> tolerant when parsing the Request-Line. In particular, they SHOULD
> accept any amount of SP or HT characters between fields, even though
> only a single SP is required.
Not applicable to this case. 3.1 says that the entire HTTP-Version
is a [single] field, so inter-field spacing rules are irrelevant.
(Also, this would contradict any prohibition on HT in the Request-
Line from 5.1.)
--
Michael Wojcik michael...@microfocus.com
Don't forget your fighting spirit at each balls you pitch!
-- Tornado Boy Volunteer Staff International
James Antill
> In article <pan.2006.09.14....@and.org>, James Antill <james-...@and.org> writes:
>> The request line is specially exempt from having CRLF TAB in the LWS
>> by 5.1.
>
> I don't see any reference to HT being prohibited in 5.1. CR and LF,
> yes.
Probably bad wording on my part. I just meant that you couldn't extend
the request line over multiple lines with the common 3 bytes[1] of
"\r\n\t", not that "\t" was invalid, even though LWS was allowed.
[1] And, obviously "\r\n " is also invalid even though it's part of LWS
(but that's less commonly used).
David Schwartz
Ben_ wrote:
> Looks like we come to an implementation decision and it'd be subject to a
> matter of taste I suppose.
I agree.
> To me, as the request is not HTTP/0.9 compliant, I'd make the server reply
> in the most widely supported standard at the time of implementation.
But you also know it's not HTTP/1.0 or HTTP/1.1 compliant. IMO, you
should not assume HTTP/1.0 or HTTP/1.1 support unless that is
negotiated, assuming you do support HTTP 0.9.
> Why not behave like an HTTP/1.0 or HTTP/1.1 server, as we known it's not a
> valid HTTP/0.9 request ?
Because it's also not a valid HTTP/1.0 or HTTP/1.1 request. You
basically have no idea what the client will make of any data you send
it.
If you support HTTP/0.9, you have to assume you might be talking to a
client with HTTP/0.9 semantics. In HTTP 0.9, any data you send as a
reply will be considered a valid payload. So the only safe solution is
to send nothing and close the connection.
However, this provides no oppurtunity to debug.
Basically, there is no wrong or right. We're trying to respond to a
condition that we know can't happen, so anything safe is fine. (That
is, crashing would be unacceptable.)
For any behavior you can argue for, I can equally well argue against.
It's a matter of taste, and there's a tradeoff between safety and
convenience. Sending nothing is the only safe behavior, but that's not
very convenient.
DS
Ben_
the lack of popularity of 0.9 clients and its so limited set of features.
As it's simple enough, I could make my server support it, but I wouldn't
want to promote that protocol too much, so I'd make the server reply in
HTTP/1.0 or 1.1 in case of syntax errors in a request.
Now, I still have to choose between 1.0 and 1.1...
Michael Wojcik
In article <pan.2006.09.16....@and.org>, James Antill <james-...@and.org> writes:
> On Fri, 15 Sep 2006 18:15:25 +0000, Michael Wojcik wrote:
> > In article <pan.2006.09.14....@and.org>, James Antill <james-...@and.org> writes:
> >> The request line is specially exempt from having CRLF TAB in the LWS
> >> by 5.1.
> >
> > I don't see any reference to HT being prohibited in 5.1. CR and LF,
> > yes.
>
> Probably bad wording on my part. I just meant that you couldn't extend
> the request line over multiple lines with the common 3 bytes[1] of
> "\r\n\t", not that "\t" was invalid, even though LWS was allowed.
Ah, the line-continuation form of LWS. I see what you meant now.
--
Michael Wojcik michael...@microfocus.com