List of HTTP errors? - TCP-IP

This is a discussion on List of HTTP errors? - TCP-IP ; In article , James Antill writes: > On Wed, 13 Sep 2006 15:04:55 +0000, Michael Wojcik wrote: > > In article , "David Schwartz" writes: > >> samer wrote: > >> > >> > but that does not help me ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 25 of 25

Thread: List of HTTP errors?

  1. Re: List of HTTP errors?


    In article , James Antill writes:
    > 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.


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

    Don't forget your fighting spirit at each balls you pitch!
    -- Tornado Boy Volunteer Staff International

  2. Re: List of HTTP errors?

    On Fri, 15 Sep 2006 18:15:25 +0000, Michael Wojcik wrote:

    > In article , James Antill 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).

    --
    James Antill -- james@and.org
    http://www.and.org/and-httpd


  3. Re: List of HTTP errors?


    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


  4. Re: List of HTTP errors?

    I didn't mention that my point for not talking HTTP/0.9 but 1.0 or 1.1 is
    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...



  5. Re: List of HTTP errors?


    In article , James Antill writes:
    > On Fri, 15 Sep 2006 18:15:25 +0000, Michael Wojcik wrote:
    > > In article , James Antill 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.wojcik@microfocus.com

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2