4 ms·

"This issue was addressed by ignoring incomplete HTTP header lines." I hope they've taken into account the fact that the value of a HTTP header can span multip

"This issue was addressed by ignoring incomplete HTTP header lines." I hope they've taken into account the fact that the value of a HTTP header can span multiple lines (RFC2616 section 4.2)

MichaelGG 13y ago
What is support like for the terrible line-folding (and comments) part of the specification? In SIP land, which copied HTTP then messed it up even further, there is no correct handling of such messages. Some SIP stacks will error, some will ignore, some will do it correctly. Thus you can't trust your proxy and server to come to the same conclusions and perform the same operations or apply the same security policy. There's no good reason for line folding or comments. Protocols need only be human readable not human easily-composed-for-formatting. This isn't the 60s or early 70s where you're writing all emails and headers by hand.
- rbanffy 13y ago
  > Protocols need only be human readable not human easily-composed-for-formatting. No, but being so is incredibly convenient. > This isn't the 60s or early 70s where you're writing all emails and headers by hand. Again, no, but, again, it'd be very convenient to be able to do it.
  - jimktrains2 13y ago
    Tell that all to the HTTP2 people:(
    - rbanffy 13y ago
      Will they listen?
  - MichaelGG 13y ago
    This "convenience" (of which I highly doubt, having crafted plenty of messages by hand) comes at a major cost to implementors, both in performance and complexity and hence security. HTTP isn't a programming language. It does not benefit from crazy syntax.
    - rbanffy 13y ago
      The protocol has to be designed in a way that facilitates (or, at least, does not actively prevents) manual input. When you mention your performance concern, I have to suggest you profile the code. If your protocol handler is limited by the performance of its message parser, you must be doing something wrong. As for complexity... No. If your parser is non-trivial when compared to the rest of your stack, again, you are doing something very wrong. I am not saying to implement full line editing or anything close that. I'd just like to point out that being able to sometimes manually interact with a server is very convenient.
      - MichaelGG 13y ago
        Line folding doesn't really help manually interact or craft messages. Nor do comments. There's no real value in being able to do: Foo: ValueBegin (this is a comment) ValueEnds Versus requiring Foo: ValueBegin ValueEnds As far as performance, I must say you're incorrect. Review the nginx HTTP parser and you'll see all sorts of bitwise hacks in order to improve performance. This aligns with my own experience writing a packet capture system for a similar protocol. Having open syntax, comments and line folding being part of the problem, incredibly complicates the parser. Other moronic things are the completely arbitrary handling of header fields. Some header fields allow their value to be split over multiple lines but must treat it as if it was one line. Others use multiple headers to provide some multi-line value. There's no simple parsing, it all must be sensitive to the context. This is just stupid, yet free-text protocol authors revel in it. SIP even publishes a "torture test" RFC where they're just oh-so-pleased with the edge cases their moronic spec allows. They even suggest a parser should guess as to the message sender's intent. I'd also note that in some cases the parser is most of the stack (simple proxy scenarios, frontend security). Regardless, the fact that the rest of the stack may be complicated is not in any way an excuse for making the parser worse. This is not a programming language.
        rbanffy 13y ago
        > you'll see all sorts of bitwise hacks in order to improve performance. How much time does nginx spend parsing HTTP requests compared to waiting for network or disk IO? > SIP even publishes a "torture test" RFC This is actually very clever. I wish other protocols had something like it to help weed out partial and buggy implementations. > They even suggest a parser should guess as to the message sender's intent. This may be a little bit too much > This is not a programming language. A lot of incredibly powerful uses for technology come precisely from the unintended scenarios - the clever ways to abuse technology and force it to do something it was never intended to. Remember HTTP itself was conceived to do a tiny subset of what it does now.

"This issue was addressed by ignoring incomplete HTTP header lines." I hope they've taken into account the fact that the value of a HTTP header can span multiple lines (RFC2616 section 4.2)

MichaelGG 13y ago

What is support like for the terrible line-folding (and comments) part of the specification? In SIP land, which copied HTTP then messed it up even further, there is no correct handling of such messages. Some SIP stacks will error, some will ignore, some will do it correctly. Thus you can't trust your proxy and server to come to the same conclusions and perform the same operations or apply the same security policy. There's no good reason for line folding or comments. Protocols need only be human readable not human easily-composed-for-formatting. This isn't the 60s or early 70s where you're writing all emails and headers by hand.

rbanffy 13y ago
> Protocols need only be human readable not human easily-composed-for-formatting. No, but being so is incredibly convenient. > This isn't the 60s or early 70s where you're writing all emails and headers by hand. Again, no, but, again, it'd be very convenient to be able to do it.
- jimktrains2 13y ago
  Tell that all to the HTTP2 people:(
  - rbanffy 13y ago
    Will they listen?
- MichaelGG 13y ago
  This "convenience" (of which I highly doubt, having crafted plenty of messages by hand) comes at a major cost to implementors, both in performance and complexity and hence security. HTTP isn't a programming language. It does not benefit from crazy syntax.
  - rbanffy 13y ago
    The protocol has to be designed in a way that facilitates (or, at least, does not actively prevents) manual input. When you mention your performance concern, I have to suggest you profile the code. If your protocol handler is limited by the performance of its message parser, you must be doing something wrong. As for complexity... No. If your parser is non-trivial when compared to the rest of your stack, again, you are doing something very wrong. I am not saying to implement full line editing or anything close that. I'd just like to point out that being able to sometimes manually interact with a server is very convenient.
    - MichaelGG 13y ago
      Line folding doesn't really help manually interact or craft messages. Nor do comments. There's no real value in being able to do: Foo: ValueBegin (this is a comment) ValueEnds Versus requiring Foo: ValueBegin ValueEnds As far as performance, I must say you're incorrect. Review the nginx HTTP parser and you'll see all sorts of bitwise hacks in order to improve performance. This aligns with my own experience writing a packet capture system for a similar protocol. Having open syntax, comments and line folding being part of the problem, incredibly complicates the parser. Other moronic things are the completely arbitrary handling of header fields. Some header fields allow their value to be split over multiple lines but must treat it as if it was one line. Others use multiple headers to provide some multi-line value. There's no simple parsing, it all must be sensitive to the context. This is just stupid, yet free-text protocol authors revel in it. SIP even publishes a "torture test" RFC where they're just oh-so-pleased with the edge cases their moronic spec allows. They even suggest a parser should guess as to the message sender's intent. I'd also note that in some cases the parser is most of the stack (simple proxy scenarios, frontend security). Regardless, the fact that the rest of the stack may be complicated is not in any way an excuse for making the parser worse. This is not a programming language.
      - rbanffy 13y ago
        > you'll see all sorts of bitwise hacks in order to improve performance. How much time does nginx spend parsing HTTP requests compared to waiting for network or disk IO? > SIP even publishes a "torture test" RFC This is actually very clever. I wish other protocols had something like it to help weed out partial and buggy implementations. > They even suggest a parser should guess as to the message sender's intent. This may be a little bit too much > This is not a programming language. A lot of incredibly powerful uses for technology come precisely from the unintended scenarios - the clever ways to abuse technology and force it to do something it was never intended to. Remember HTTP itself was conceived to do a tiny subset of what it does now.