Live data from Hacker News

Post Mortem: A single whitespace character

eatabit.com

111–120 of 209 posts

Re: Post Mortem: A single whitespace character

#111

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…

Those would be "safe" (assuming that settings.getIMEI() is completely under your control, everything else is string literals) but yeah snprintf seems way better here (though it's been well over 20 years since I wrote any significant C code.

Re: Post Mortem: A single whitespace character

#112

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…

In particular this philosophy is rejected in the Erlang community, where they prefer "crash if anything is not what you expect it to be"

Re: Post Mortem: A single whitespace character

#114

Earlier quoted context omitted.

Why? it's just pizza

Yes, it's just pizza - no ccards or personal information is transmitted - except your choice of toppings. Could that be used to profile you? "...paging Dr. Freud"

But aren't the API credentials are transmitted there as well? You don't care if your API is compromised?

Re: Post Mortem: A single whitespace character

#115

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…

Those would be "safe" (assuming that settings.getIMEI() is completely under your control, everything else is string literals) but yeah snprintf seems way better here (though it's been well over 20 years since I wrote any significant C code.

Possibly safe but definitely inefficient, since it has to find the end of the string to know where the destination pointer starts. The right way is to keep a pointer to the end.

(Or since they are already using std::string in other places, maybe just do that everywhere, I'm sure it makes better choices than they did here.)

The pointer cast thing is glaring. Why not simply declare the buffer as a char array and be done with it, instead of casting at every use? IMO over-use of pointer casts is a clear sign someone is lost in the language, your goal should be to reduce them.

Re: Post Mortem: A single whitespace character

#116

Earlier quoted context omitted.

Those would be "safe" (assuming that settings.getIMEI() is completely under your control, everything else is string literals) but yeah snprintf seems way better here (though it's been well over 20 years since I wrote any significant C code.

Possibly safe but definitely inefficient, since it has to find the end of the string to know where the destination pointer starts. The right way is to keep a pointer to the end. (Or since they are already using std::string in other places, maybe just do that everywhere, I'm sure it makes better choices than they did here.) The pointer cast thing is glaring. Why not simply declare the buffer as a char array and be don…

Yeah agree, to me casts like that are a smell that someone is trying to squash compiler complaints rather than understanding them. It also has every appearance of "copy/paste" code writing.

Re: Post Mortem: A single whitespace character

#117
Assuming the problem originates from something relating to eatabit's infrastructure, the important takeway (for me) would be: Depend as little on 3rd parties as possible.

I know this is not a popular opinion among the HN crowd, mainly due to the entire web's love of linking to some other site's js/css to offload cost from their own site. But this makes no sense; you're not really reducing costs, you're just delaying them.

People talk about how 3rd parties speed up development or (potentially) reduce costs. But if the success of your business depends on providing a service all the time that has to be reliable, the reliability of your product is directly proportional to the reliability of the 3rd party. And each 3rd party adds additional points of failure. If you don't control whatever service or product the 3rd party is giving you, you will be unable to even attempt to isolate and fix it yourself.

Typically the answer to this problem is 'buy a better service contract'. But if the 3rd party doesn't provide 24/7 365 support along with multiple contact methods and harsh penalties for failing to supply you with timely service, you're wasting your money. You don't want to be the guy who has to tell the CIO "Sorry, I can't get a hold of our service provider or they aren't giving me timely updates, so I do not know when our product will be up again."

Re: Post Mortem: A single whitespace character

#118

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…

> The client actually failed to adhere to the "be strict in what you issue" principal

Well, that's the rub, right? How do you know how strict you're being if your tools accept things liberally? If anything, the lesson here is to test with the strictest possible tools.

> just as the Cowboy was not liberal in accepting

And this is hard too, because on what dimensions should you be liberal? How do you decide what the "real" set of inputs you're going to accept?

And that leads to my real issue with the principle: what should you, as the liberal accepter, do in those cases? Here it's easy enough to guess what the behavior should be with the extra space (just accept the damn request), but in general it's not -- you're creating implementation-specific behavior; what happens when you accept undefined or incorrect inputs will vary from implementation to implementation, creating a nightmare of uncertainty for people sending you stuff. Of course, you can always say, "they should send stricter stuff!" but then what's really the point of accepting inputs liberally?

Re: Post Mortem: A single whitespace character

#119

Earlier quoted context omitted.

I'm just curious why the default response is still to reach for an Arduino--much more powerful SoC chips are cheap these days.

For us, the reason is that my co-founder and I (both are not hardware guys) were able to build a proof of concept in my garage and Arduino seemed like the best (easiest) choice. Since then, we hired a hardware guy who designed a custom PCB etc. HTTPS would be great but we don't transmit any personal data so it's not a high priority right now.

> HTTPS would be great but we don't transmit any personal data so it's not a high priority right now.

You are sending people's orders around the web. I'd consider that "personal".

None-the-less, use SSL, there is little reason not to use it these days. And as others have pointed out, it's the only good and easy way to guarantee what you send to one of these printers is what it actually received (no carrier tampering of your packets, etc).

Just use SSL.

Re: Post Mortem: A single whitespace character

#120

Earlier quoted context omitted.

Why don't you guys just use a Beaglebone Black ($50), M2M cape ( http://www.yantrr.com/products/m2m-cape-for-beaglebone ), and a thermal printer ( https://www.sparkfun.com/products/10438 ). BOM for that, plus project enclosure, is like $200. That's also just after a bit of quick googling...there's bound to be a much cheaper solution. What's your price point for hardware?

We are at about $200 now for hardware. We have a custom PCB and 3d printed case. We also have an LCD and some control knobs in the mix. Checking out the Beaglebone stuff now...very interesting since there is basically no 3G/4G modems for Arduino right now...

if you buy a batch of beaglebones from adafruit.com or another, perhaps larger mid-tier distributor, you can likely get a discount per unit.
Post reply on HN