5 ms·
https://www.ietf.org/rfc/rfc2616.txt https://www.ietf.org/rfc/rfc2616.txt : "All linear white space, including folding, has the same semantics as SP." So only o
by oever 12y ago
https://www.ietf.org/rfc/rfc2616.txt https://www.ietf.org/rfc/rfc2616.txt :
"All linear white space, including folding, has the same semantics as SP."
So only one space need be counted and any subsequent space or horizontal tab can be ignored. Your example simplifies to:
Foo: Hello World\r\n
Bar: smeg
- nly 12y agoIt doesn't matter that the obs-fold can be treated as a single space because you don't know that until you've actually reached the fold. Consider: Foo: Hello_______world\r\n Here the whitespace has to be preserved, as per the field-content production. So RFC2616 allowed: Foo: Hello_______\r\n ____world\r\n to be reduced to: Foo: Hello world\r\n Incidentally RFC7230 (it's successor) says something subtly different: "A server that receives an obs-fold in a request message that is not within a message/http container MUST either reject the message by sending a 400 (Bad Request), preferably with a representation explaining that obsolete line folding is unacceptable, or replace each received obs-fold with one or more SP octets prior to interpreting the field value or forwarding the message downstream." So now it's been loosened to one or more SP octets... useful, except there's no mention of TAB octets, which can follow a CRLF as part of an obs-fold... so you still can't just remove the CRLF and preserve all the whitespace... preserving tabs would be illegal. So the new rules don't help streaming either. Joyents parser did this regardless (not sure if it still does). You'll also notice it says the obs-fold can be replaced with a sequence of SP characters... according to the grammar that's the CRLF and the following whitespace, not any whitespace preceding the CRLF. You'd think that would be helpful because it means any whitespace before the CRLF can always be streamed as part of the field value, right? Except... Foo: Hello_______\r\n ____\r\n would still simplify to: Foo: Hello_______[one or more SP octets]\r\n and then what? Well, presumably you then have to trim off the trailing whitespace to produce a value of just "Hello"... so all the whitespace you buffered before you reached the CRLF (in case you reached another field-vchar like the 'w' in 'world') has to be discarded.
- Retric 12y agoAssuming your reading this from a buffer and most of the time you don't need to count then store an index to the o in hello followed by ignoring space. Then to back and count it only if you need to. Or better yet if whitespace is not need just copy a space but if it's needed then move those bytes to the next stage and don't bother to count them that go around.
- nly 12y ago... and what happens if your header happens to run off the end of your buffer amongst the spaces that follow 'Hello'? Cookies can be huge, I can construct a header like 'Cookie: x[8000 spaces]y'
- Retric 12y agoThis get's into the specifics so you almost need to know the code your dealing with to make a relevant suggestion. However, the easy option is to default to the slow code path on edge cases which considering it's probably a rare enough it's not important to make fast as long it's bug free. IMO, optimizations are always a balancing act between minimizing the computer's effort and minimizing the coders effort while trying to maintain long term readability. But, you can always keep track of more than one buffer so the option is there.