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

191–200 of 209 posts

Re: Post Mortem: A single whitespace character

#191

Post by rtpg »

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 think the core issue here is that we're directly manipulating strings instead of using DSLs and tooling based around grammars to build our responses (this has been a solved problem for more than 10 years!)

I'm a strong proponent of "do not manipulate strings". Having library writers be the only one doing that would greatly reduce the attack surface/bug potential.

Re: Post Mortem: A single whitespace character

#192

Post by stevewilhelm »

peterwwillis wrote: post #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…

> Depend as little on 3rd parties as possible.

This attitude has many a startup reinventing and supporting commodity infrastructure instead of focusing on developing unique products and value for their customers.

Re: Post Mortem: A single whitespace character

#193

Post by lmb »

Filligree wrote: post #131
goleksiak wrote: post #69

Earlier quoted context omitted.

We would really like to use HTTPS but it's not supported by the Arduino chipset as I understand it. Though I'm not the hardware guy here at eatabit...

Then, don't use SSL if it's too heavyweight. I know everyone will tell you not to roll your own cryptosystem, but rolling your own is superior to having no encryption or authentication, and so long as you're sane about it the result should be no worse than passing plaintext. Your messages are small. Encrypt (or maybe just sign) them with RSA and call it a day. You don't really need to use port 80 and a HTTP preface a…

That is pretty bad advice. RSA is slow, needs a lot of memory and is difficult to get right. Just go with AES in CTR mode if you absolutely have to. And remember that encryption != authentication.

Re: Post Mortem: A single whitespace character

#194

Post by lmb »

swordswinger12 wrote: post #147
goleksiak wrote: post #69

Earlier quoted context omitted.

We would really like to use HTTPS but it's not supported by the Arduino chipset as I understand it. Though I'm not the hardware guy here at eatabit...

You guys build all the hardware - why not just use one of the pre-shared key TLS ciphersuites? No expensive public-key crypto required, just AES and SHA.

Last time I checked (about a year ago), support for PSK was pretty abysmal on the server side of things.

Re: Post Mortem: A single whitespace character

#195

Post by leni536 »

WBrentWilliams wrote: post #177
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…

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".

It's quite a game theoretical problem. Make a strictly standard compliant browser and nobody will use it, since it won't display most of the websites. You have to render badly formed pages somehow if you want your browser compete with other browsers, since they are doing the same.

Re: Post Mortem: A single whitespace character

#196

Post by ldng »

fulafel wrote: post #167
ldng wrote: post #158

Earlier quoted context omitted.

What's wrong with transparent proxy ? Isn't how HTTP caching is supposed to work ? I would think the cache headers are the solution rather than SSL. It feels like you are kind of throwing the baby with the bath water. IMHO, badly configured transparent proxy does not mean the concept is bad, does it ?

No, "transparent proxying" is a clear violation of HTTP specs (as well as TCP protocol, and IP's "thou shall not mess with packets in transit" principle/specs). It's essentially a MITM attack and all bets are off wrt correctness.

We'll disagree then :)

From RFC 2616 "The HTTP/1.1 protocol allows origin servers, caches, and clients to explicitly reduce transparency when necessary."

As I said, bad configurations dos not mean the principle is unsound.

Re: Post Mortem: A single whitespace character

#197

Post by gpvos »

lmm wrote: post #110
gpvos wrote: post #64

Earlier quoted context omitted.

But then the server may still decide that an empty segment is so meaningless that it will refuse it. In fact, it would not be a smart move to just treat double slashes the same as single ones, because of relative URLs: a ".." segment only removes one slash, so the hierarchy levels would get messed up. thttpd is doing the smart thing here. As one of my teachers at university would say: the empty segment is also a segm…

The server can of course interpret the path as it wants, but it should allow an application running under the server to give 'foo//bar' a meaning if that application wants to, IMO.

True. I was writing about the case when the URL simply mapped to a file system location. Applications should be able to apply their own interpretation.

Re: Post Mortem: A single whitespace character

#198

Post by curveship »

angersock wrote: post #94
goleksiak wrote: post #87

Earlier quoted context omitted.

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...

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

One reason to still use an Arduino is realtime. The arduino's minimalist OS is realtime by default, but the BBB runs non-realtime Debian. They might need RT timings for the printer interface? You can add realtime linux extensions to BBB, but it's not a beginner task -- basically rolling your own Linux installation and writing your app as a kernel module. You can also use the PRU on the BBB to get insane RT performance, but you'll have to code it in assembly. I love the BBB, but Arduino is still an easier package for simple realtime.

Re: Post Mortem: A single whitespace character

#199

Post by pessimizer »

robomartin wrote: post #151
DanBC wrote: post #132

Earlier quoted context omitted.

> But I see a few common patterns on HN all the time > A post such as mine would not have to appear too frequently Which is it? All the time or not too frequently? And while you might only make rare posts some people would point out every error and mistake and difference in style. People downvote your post to dissuade those other posts. About your downvotes: I'm guessing they're for your incredible arrogance. https:/…

It's easy to make someone sound arrogant by (a) taking comments completely out of context and (b) not bothering to understand the frame of reference by at least asking the question. HN only does well with well defined technical discussion. On everything else it has degraded to almost what happened to every USENET list in the past. USENET did not have any voting mechanism to make opposing views disappear. In that case…

I agree with you 100% about the English correction, but you do an awful lot of complaining about the field rather than admitting that there was something wrong with your play, and occasionally some thinking that you know the demographics of the person you're taking to, and disqualifying of that person's participation in the discussion based on that fiction.

Notice that your correction is in the black, but these complaints are in the grey.

Unpopular opinions do have a lot of trouble on HN, but I think that dang's efforts with algorithms and intervention have improved the situation, and at least show good intent.

I attract downvotes like honey attracts flies, but I deserve them. I really disagree, and am happy to repeat myself. I double-down on my most downvoted comments; people may not know quite how much they disagree with me unless I expand on what I said.

>risk being called arrogant

Not very high risk then? Sounds like a very safe place.

Re: Post Mortem: A single whitespace character

#200

Post by fulafel »

ldng wrote: post #196
fulafel wrote: post #167

Earlier quoted context omitted.

No, "transparent proxying" is a clear violation of HTTP specs (as well as TCP protocol, and IP's "thou shall not mess with packets in transit" principle/specs). It's essentially a MITM attack and all bets are off wrt correctness.

We'll disagree then :) From RFC 2616 "The HTTP/1.1 protocol allows origin servers, caches, and clients to explicitly reduce transparency when necessary." As I said, bad configurations dos not mean the principle is unsound.

No, RFC 2616 uses transparency in a different meaning that the common usage of "transparent proxy" is.

Common meaning (from https://en.wikipedia.org/wiki/Proxy_server#Transparent_proxy): "Also known as an intercepting proxy, inline proxy, or forced proxy, a transparent proxy intercepts normal communication at the network layer"

RFC 2616 uses the term to describe a property of a normal, opt-in HTTP proxy: "A 'transparent proxy' is a proxy that does not modify the request or response"

In preceding discussion we were using the term in its common usage meaning.

Also, you misrepresent what RFC 2616 says about the its concept of transparency. The part you quoted continues:

  "the protocol requires that transparency be relaxed

      - only by an explicit protocol-level request when
        relaxed by client or origin server

      - only with an explicit warning to the end user when relaxed by
        cache or client "
Post reply on HN