List of HTTP errors? - TCP-IP

This is a discussion on List of HTTP errors? - TCP-IP ; How do I find a systematic way to know what kind of an error message 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 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 25

Thread: List of HTTP errors?

  1. List of HTTP errors?

    How do I find a systematic way to know what kind of an error message
    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?


  2. Re: List of HTTP errors?


    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


  3. Re: List of HTTP errors?

    In article <1158094652.979631.37300@i42g2000cwa.googlegroups.c om>,
    "David Schwartz" 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, barmar@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 ***

  4. Re: List of HTTP errors?


    Barry Margolin wrote:

    > In article <1158094652.979631.37300@i42g2000cwa.googlegroups.c om>,
    > "David Schwartz" 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


  5. Re: List of HTTP errors?

    In article <1158113354.516322.198550@i3g2000cwc.googlegroups.c om>,
    "David Schwartz" wrote:

    > Barry Margolin wrote:
    >
    > > In article <1158094652.979631.37300@i42g2000cwa.googlegroups.c om>,
    > > "David Schwartz" 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.

    --
    Barry Margolin, barmar@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 ***

  6. Re: List of HTTP errors?


    In article <1158094652.979631.37300@i42g2000cwa.googlegroups.c om>, "David Schwartz" 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.wojcik@microfocus.com

    Only the obscene machine has persisted
    jerky and jockeying and not knowing why
    I have never existed. Nor should. -- George Barker

  7. Re: List of HTTP errors?


    In article , Barry Margolin writes:
    > In article <1158094652.979631.37300@i42g2000cwa.googlegroups.c om>,
    > "David Schwartz" wrote:
    > > samer wrote:
    > >
    > > > GET /~ross/ HTTP/ 4.5

    >
    > > 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.wojcik@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"

  8. Re: List of HTTP errors?

    > 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 ?
    Closing the connection without telling why is not informative and makes it
    harder to troubleshoot...



  9. Re: List of HTTP errors?


    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


  10. Re: List of HTTP errors?


    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


  11. Re: List of HTTP errors?


    "David Schwartz" wrote in message
    news:1158175009.543350.21050@h48g2000cwc.googlegro ups.com...
    >
    > 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
    >


    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.



  12. Re: List of HTTP errors?


    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


  13. Re: List of HTTP errors?

    In article <1158175009.543350.21050@h48g2000cwc.googlegroups.c om>,
    "David Schwartz" wrote:

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


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

    --
    Barry Margolin, barmar@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 ***

  14. Re: List of HTTP errors?


    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


    400 Bad Request

    Bad Request


    Your browser sent a request that this server could not
    understand.




    Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g Server at
    www.apache.org Port 80


    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


    400 Bad Request

    Bad Request


    Your browser sent a request that this server could not
    understand.




    Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g Server at
    www.apache.org Port 80


    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


    400 Bad Request

    Bad Request


    Your browser sent a request that this server could not
    understand.




    Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g Server at
    www.apache.org Port 80


    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


  15. Re: List of HTTP errors?

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

    You learned me something, thx.


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



  16. Re: List of HTTP errors?


    In article <45082523$0$5529$ba620e4c@news.skynet.be>, "Ben_" 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.wojcik@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!

  17. Re: List of HTTP errors?


    In article , Barry Margolin 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.wojcik@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_

  18. Re: List of HTTP errors?

    In article ,
    Michael Wojcik 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 vjs@rhyolite.com

  19. Re: List of HTTP errors?

    On Wed, 13 Sep 2006 15:04:55 +0000, Michael Wojcik wrote:

    >
    > In article <1158094652.979631.37300@i42g2000cwa.googlegroups.c om>, "David Schwartz" 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 -- james@and.org
    http://www.and.org/and-httpd


  20. Re: List of HTTP errors?


    In article , vjs@calcite.rhyolite.com (Vernon Schryver) writes:
    > In article ,
    > Michael Wojcik 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.


    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.wojcik@microfocus.com

    The guy who's fast in the mountain pass is the coolest.
    -- _Initial D: Second Stage_

+ Reply to Thread
Page 1 of 2 1 2 LastLast