Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Post Mortem: A single whitespace character

eatabit.com

Post reply on HN
Print view View original

171–180 of 209 posts

Re: Post Mortem: A single whitespace character

#171

Post by MichaelGG »

TheLoneWolfling wrote: post #139
jrochkind1 wrote: post #133

Earlier quoted context omitted.

The problem is that "be liberal in what you accept" is, by definition, saying to go beyond the standards, accepting things that are technically illegal according to the standards. So different software will necessarily do it differently. For all software to be doing it the same, there would realistically need to be some specified standard on how to do it, and then we're no longer talking about 'be liberal in what you…

How about this as a middle-ground: Be strict in what you issue (duh!), be liberal in what you accept - but both emit strong warnings when the input isn't strict, and have a strict mode.

That doesn't work. Strict mode ends up getting turned off by default, or turned off at the earliest problem. After all, what's the point in being so strict? I've seen security bugs arise from this, nicely commented in source with a "// spec says x but no need to be so pedantic".

If everyone can be strict in what's sent, then the problem is solved. But since that won't happen, even on accident, the only solution is to be harsh on receiving input and hope things fail early in the dev cycle.

Also, text-based protocols are especially prone to this poor handling, A: because spec writers (like HTTP's) go moronically overboard, being all creative (line folding? comments in HTTP headers? FFS!) and B: because text is so easy, everyone just figures anything goes and pays less attention.

Re: Post Mortem: A single whitespace character

#172

Post by MichaelGG »

codehero wrote: post #41
jrochkind1 wrote: post #7

This very example -- requests were technically illegal all the time without devs realizing, but something in the stack changed to start rejecting them -- demonstrates the fallacy of the "be liberal in what you accept, strict in what you issue" principal. If all the web servers involved had been strict in rejecting the illegal request from the start, they would have noticed the bug in development before deploying to f…

I have to agree. I developed a proprietary embedded web server using a streaming HTTP parser. Complying with the HTTP parsing rules is a headache to say the least. Variable amounts of whitespace; 2 variants of line terminators (\r\n or \n) with the provision that the latter SHOULD be accepted by the server and line continuations make complying with the whole specification a real pain if you only have 100 bytes to par…

Every appearance of SHOULD/MAY in a spec is just begging for bugs or incompatibility. We'd be better off if those words were banned. Spec writers would be less inclined (hopefully) to come up with all sorts of arbitrary behaviour that might happen and could be maybe handled.

Re: Post Mortem: A single whitespace character

#173

Post by MichaelGG »

ctz wrote: post #122
pjc50 wrote: post #82

Earlier quoted context omitted.

Is client CPU actually a limiting factor? How does this affect reliability?

You cannot physically fit a whole SSL datagram (max size 16KB) into 8KB of RAM. SSL requires multiple passes over the data to (eg) decrypt and verify a datagram. At this point, you cannot use standard SSL at either the server side or client side. On the subject of reliablity: a 8 bit uC running at 16MHz needs a long time to do the public key crypto required to set up the connection. This means you need a GSM data lin…

SSL supports a null cipher, so why not use that? The handshake alone may be enough to prevent packet inspection.

Re: Post Mortem: A single whitespace character

#174

Post by MichaelGG »

jrochkind1 wrote: post #7

This very example -- requests were technically illegal all the time without devs realizing, but something in the stack changed to start rejecting them -- demonstrates the fallacy of the "be liberal in what you accept, strict in what you issue" principal. If all the web servers involved had been strict in rejecting the illegal request from the start, they would have noticed the bug in development before deploying to f…

SIP takes this to the next level. http://tools.ietf.org/html/rfc4475 Is a spec for "torture tests", where the SIP authors revel in the hideously complex parsing rules they've come up with (which is basically HTTP parsing).

They even suggest that code should infer the meaning of messages. So I suppose you need some sort of AI to really handle things well.

Binary protocols would be a better choice. Or, a well-defined text format. JSON, XML, anything, really, would eliminate this class of bugs.

Re: Post Mortem: A single whitespace character

#175

Post by Dylan16807 »

asveikau wrote: post #97

strcpy( ( char * ) commsOrderBuffer, "GET /v1/printer/"); strcat( ( char * ) commsOrderBuffer, ( char * ) settings.getIMEI()); strcat( ( char * ) commsOrderBuffer, "/orders.txt HTTP/1.1\r\n"); strcat( ( char * ) commsOrderBuffer, "HOST: "); strcat( ( char * ) commsOrderBuffer, SERVER_NAME); strcat( ( char * ) commsOrderBuffer, "\r\n"); strcat( ( char * ) commsOrderBuffer, "Authorization: Basic "); What the.... O(n) s…

O what now? O(7) is the same as O(1)

Re: Post Mortem: A single whitespace character

#176

Post by imanaccount247 »

kstrauser wrote: post #156
imanaccount247 wrote: post #148

Earlier quoted context omitted.

>Objectively, you need to write more tests That is precisely the opposite of objective. Personal thoughts, feelings and opinions are subjective by definition. 2+2=4 is objective. "You need to put more cheese on that pizza" is subjective.

"We don't have enough test coverage to ensure that we're generating RFC-compliant output" is objective. That's not a personal though, feeling, or opinion. If you wish, you may generalize that to "we don't have enough tests to catch an error that made it into the shipped product".

That would only be objective if it were possible to have enough test coverage to ensure that. But that is not possible. So it is purely a subjective question of how much test coverage person A thinks is "good enough".

Re: Post Mortem: A single whitespace character

#177

Post by WBrentWilliams »

jrochkind1 wrote: post #133
Xylakant wrote: post #18

Earlier quoted context omitted.

I don't agree that "be liberal in what you accept, strict in what you issue" is a fallacy. The client actually failed to adhere to the "be strict in what you issue" principal, just as the Cowboy was not liberal in accepting. All software will sooner or later exhibit bugs or be stricter or more lenient about a standard. I think the fallacy is to assume that once stuff works in production, only your changes can trigger…

The problem is that "be liberal in what you accept" is, by definition, saying to go beyond the standards, accepting things that are technically illegal according to the standards. So different software will necessarily do it differently. For all software to be doing it the same, there would realistically need to be some specified standard on how to do it, and then we're no longer talking about 'be liberal in what you…

I'd say the fault with HTML/JS/CSS is that the implementation of the rendered (the browser) broke the stack by not being strict in what it emitted. Put another way, a badly formed page should render badly and/or issue errors. For historical reasons, browsers did not and do not. Hence, the reason the browsers are "broken".

Re: Post Mortem: A single whitespace character

#178

Post by SilasX »

Xylakant wrote: post #18
jrochkind1 wrote: post #7

This very example -- requests were technically illegal all the time without devs realizing, but something in the stack changed to start rejecting them -- demonstrates the fallacy of the "be liberal in what you accept, strict in what you issue" principal. If all the web servers involved had been strict in rejecting the illegal request from the start, they would have noticed the bug in development before deploying to f…

I don't agree that "be liberal in what you accept, strict in what you issue" is a fallacy. The client actually failed to adhere to the "be strict in what you issue" principal, just as the Cowboy was not liberal in accepting. All software will sooner or later exhibit bugs or be stricter or more lenient about a standard. I think the fallacy is to assume that once stuff works in production, only your changes can trigger…

Or, maybe instead of ballooning this thread with unending hairsplitting, we should recognize the principle as a heuristic that fails on non-representative or extreme cases...

Re: Post Mortem: A single whitespace character

#179

Post by goleksiak »

sixwing wrote: post #161
goleksiak wrote: post #157

Heroku came back and said: Looking through the system, I see that you were sent two emails (in August and September) as several of your apps were migrated to the new routing stack ( https://devcenter.heroku.com/articles/heroku-improved-router ). As mentioned in the documentation, the new router follows stricter adherence to the RFC specification, including sensitivity to spaces. ...and sure enough, there is a line th…

The team at Heroku (where I currently PM) is constantly trying to improve our communication and documentation. We're definitely sorry that this caused problems, and we'll work even harder to make sure that our communication calls out any potential issues. Again - thanks for reaching out to us, and let us know if we can help.

Heroku did their best here. They reached out to us (twice) advising of changes and linking to a document that describe EXACTLY the bug that we discovered (later). Honestly, I don't feel bad about his bug because even if I would have read the alert to the letter, we would not have audited the entire codebase because we don't have that luxury of time. Yes, it took our whole operation down...but we found it, fixed it and now we're back up. ...it's all in the game. -@eatabit

Re: Post Mortem: A single whitespace character

#180

Post by asveikau »

Dylan16807 wrote: post #175
asveikau wrote: post #97

strcpy( ( char * ) commsOrderBuffer, "GET /v1/printer/"); strcat( ( char * ) commsOrderBuffer, ( char * ) settings.getIMEI()); strcat( ( char * ) commsOrderBuffer, "/orders.txt HTTP/1.1\r\n"); strcat( ( char * ) commsOrderBuffer, "HOST: "); strcat( ( char * ) commsOrderBuffer, SERVER_NAME); strcat( ( char * ) commsOrderBuffer, "\r\n"); strcat( ( char * ) commsOrderBuffer, "Authorization: Basic "); What the.... O(n) s…

O what now? O(7) is the same as O(1)

Yeah I'll admit I was a little fast and loose with that. O(n + m), where n is the length of the (pre-concatenation) destination and m is the length of the source. Do that enough times and you get a quadratic looking curve. My point was it's easy to get to O(m).
Post reply on HN