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

The HTTP crash course nobody asked for

fasterthanli.me

Post reply on HN
Print view View original

101–110 of 149 posts

Re: The HTTP crash course nobody asked for

#101

Post by Reventlov »

jandrese wrote: post #97
danuker wrote: post #12

Earlier quoted context omitted.

How is WiFi so much more reliable than Bluetooth? I installed a web server on my phone and send files this way much faster (and Android -> Apple works): https://f-droid.org/en/packages/net.basov.lws.fdroid/ I wish there were a standard for streaming (headphones could connect to your network via WPS, and stream some canonical URL with no configuration needed).

Bluetooth is massively more complicated than WiFi. It has a whole service enumeration/discovery layer baked in that IMHO tried to cram way too much into the spec. Whats even more amazing is that some of the hardware vendors at the table during the development went "F that" and added some side channel audio stuff that bypassing most of the stack. But mostly the problem is that too much of this complexity fell on hardw…

> Bluetooth is massively more complicated than WiFi. It has a whole service enumeration/discovery layer baked in that IMHO tried to cram way too much into the spec. Whats even more amazing is that some of the hardware vendors at the table during the development went "F that" and added some side channel audio stuff that bypassing most of the stack.

I seriously think you underestimate the complexity in Wi-Fi networks. The 802.11 2020 standard is 4379 pages long. And i'm not even counting the amendments ( https://www.ieee802.org/11/Reports/802.11_Timelines.htm ) that are in development.

Re: The HTTP crash course nobody asked for

#102

Post by Reventlov »

masklinn wrote: post #26
danuker wrote: post #12

Earlier quoted context omitted.

How is WiFi so much more reliable than Bluetooth? I installed a web server on my phone and send files this way much faster (and Android -> Apple works): https://f-droid.org/en/packages/net.basov.lws.fdroid/ I wish there were a standard for streaming (headphones could connect to your network via WPS, and stream some canonical URL with no configuration needed).

> How is WiFi so much more reliable than Bluetooth? WiFi uses near 10x the power Bluetooth does when active (and that’s before factoring in BLE which cuts that down in half). WiFi also has access to the much less crowded 5GHz band. IIRC WiFi is also a much simpler protocol, it’s just a data channel (its aim being to replace LAN cables). Plus in order to support cheap and specialised devices Bluetooth supports all sor…

>IIRC WiFi is also a much simpler protocol, it’s just a data channel (its aim being to replace LAN cables).

I'm not sure what do you mean, but Wi-Fi covers the PHY layer and the MAC layers. It's not « only » a data channel. Modern Wi-Fi uses OFDMA, which is arguably more complex than what bluetooth uses (without even talking about the MAC).

Re: The HTTP crash course nobody asked for

#103

Post by dbttdft »

mgaunard wrote: post #67
X-Istence wrote: post #63

> This is not the same as HTTP pipelining, which I will not discuss, out of spite. That is cause HTTP pipelining was and is a mistake and is responsible for a ton of http request smuggling vulnerabilities because the http 1.1 protocol has no framing. No browser supports it anymore, thankfully.

Isn't "HTTP pipelining" just normal usage of HTTP/1.1? Anyone that doesn't support this is broken. My own code definitely does not wait for responses before sending more requests, that's just basic usage of TCP.

Not even just TCP, basic usage of message passing and any data flow.

Re: The HTTP crash course nobody asked for

#104

Post by dbttdft »

chrismorgan wrote: post #31
Joker_vD wrote: post #17

> HTTP/1.1 is a delightfully simple protocol, if you ignore most of it. As someone who had to write a couple of proxy servers, I can't express how so sadly accurate it is.

And this is why I expect HTTP/2 and HTTP/3 to be much more robust in the long term: the implementations are harder to write, and you won’t get anywhere without reading at least a some spec, whereas HTTP/1 is deceptively simple with therefore a lot of badly incorrect implementations, often with corresponding security problems.

I don't think I could implement a correct HTTP 1 agent even if I read the specs.

Re: The HTTP crash course nobody asked for

#106

Post by bmitc »

chrismorgan wrote: post #31
Joker_vD wrote: post #17

> HTTP/1.1 is a delightfully simple protocol, if you ignore most of it. As someone who had to write a couple of proxy servers, I can't express how so sadly accurate it is.

And this is why I expect HTTP/2 and HTTP/3 to be much more robust in the long term: the implementations are harder to write, and you won’t get anywhere without reading at least a some spec, whereas HTTP/1 is deceptively simple with therefore a lot of badly incorrect implementations, often with corresponding security problems.

> whereas HTTP/1 is deceptively simple with therefore a lot of badly incorrect implementations

Doesn't that imply that HTTP/1 is deceptively complex?

Re: The HTTP crash course nobody asked for

#107

Post by kortex »

Reventlov wrote: post #102
masklinn wrote: post #26

Earlier quoted context omitted.

> How is WiFi so much more reliable than Bluetooth? WiFi uses near 10x the power Bluetooth does when active (and that’s before factoring in BLE which cuts that down in half). WiFi also has access to the much less crowded 5GHz band. IIRC WiFi is also a much simpler protocol, it’s just a data channel (its aim being to replace LAN cables). Plus in order to support cheap and specialised devices Bluetooth supports all sor…

>IIRC WiFi is also a much simpler protocol, it’s just a data channel (its aim being to replace LAN cables). I'm not sure what do you mean, but Wi-Fi covers the PHY layer and the MAC layers. It's not « only » a data channel. Modern Wi-Fi uses OFDMA, which is arguably more complex than what bluetooth uses (without even talking about the MAC).

I think WiFi is better abstracted and layer-delineated though. Wifi has a lot of complexity but it largely feels like necessary complexity, and the physical layer, data layer, and application layer all mostly stay in their lane. Bluetooth is a mishmash of accidental complexity with physical layer leaking data layer abstraction, and the application/data boundary is even more blurred. Instead of dumb pipes, you have to worry about codecs and the like, of which there are myriad vendor specific ones.

Re: The HTTP crash course nobody asked for

#108

Post by mcspiff »

Icathian wrote: post #46

Amos' writing style is just so incredibly good. I don't know anyone else doing these very long-form, conversational style articles. Plus, you know, just an awesome dev who knows his stuff. Huge fan.

https://xeiaso.net/ is equally great content in a similar style in my opinion. Different area of topics a bit, but I enjoy both very much

Re: The HTTP crash course nobody asked for

#109

Post by jefftk »

mistrial9 wrote: post #84
jefftk wrote: post #83

Earlier quoted context omitted.

> I will believe this when I see it, thank you I'm on my phone so I can't confirm this is http3, but how about https://self-signed.badssl.com/

ok $ curl -v https://self-signed.badssl.com/ * Trying 104.154.89.105:443... * Connected to self-signed.badssl.com (104.154.89.105) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.0 (OUT), TLS header, Certificate Status (22): * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS header, Certificate Status (22): *…

Among other things that's saying it's a self-signed cert and can do HTTP2. So that Chrome on my phone will connect to it does confirm that you can do self-signed certs with HTTP2 at least.

Re: The HTTP crash course nobody asked for

#110

Post by jefftk »

mistrial9 wrote: post #96
benmmurphy wrote: post #89

Earlier quoted context omitted.

curl -kv https://self-signed.badssl.com/ * Trying 104.154.89.105:443... * TCP_NODELAY set * Connected to self-signed.badssl.com (104.154.89.105) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /opt/local/share/curl/curl-ca-bundle.crt CApath: none * TLSv1.2 (OUT), TLS header, Certificate St…

yes minus-k says "less checking, generally proceed" but does it remember that certificate? maybe not

I wouldn't want curl to remember the exception. It's not like a browser: just because I'm currently testing a site with -k does not mean I never want it to perform the normal careful checks.
Post reply on HN