61–70 of 84 posts
A bit offtopic, but does anybody know what typesetting system was used to produce this document? It looks like troff manpages. Is that what is used for RFC documents as well? I love the oldschool look of it.
Earlier quoted context omitted.
Ah, I get it. Thanks to you and bostonvaulter2. It'd be interesting to see whether adding authentication/sign on to a protocol like DHCP would fit better. The hijacking of HTTP, while it obviously works well in the default case, seems nasty and this error code fixes the wrong problem. Better to have a DHCP field that tells you to visit a specific website to log in; then the OS could display that website when you conn…
This seems rational, but it’s too much complexity for too little gain. If no one have solved this problem in the last 10 years, it won’t happen now.
Earlier quoted context omitted.
It has nothing to do with security, but it's not pointless. It tells the client that this response did not come from the server it attempted to contact. This is especially useful for non-browser clients that will otherwise simply choke on the 302 redirect normally used for this purpose, but it could also be useful for browsers to present a better UI for signing on to the internet. My only concern is that 511 could be…
> My only concern is that 511 could be seen as legitimizing the practice of putting silly click-through terms-of-service roadblocks on free wi-fi (making it impossible for devices to connect without a human operating a web browser), but since people are doing it anyway we might as well support it properly. Filter on User-Agent to only show terms to browser. If non-human agent spoofs browser signature, it’s their own…
Earlier quoted context omitted.
It has nothing to do with security, but it's not pointless. It tells the client that this response did not come from the server it attempted to contact. This is especially useful for non-browser clients that will otherwise simply choke on the 302 redirect normally used for this purpose, but it could also be useful for browsers to present a better UI for signing on to the internet. My only concern is that 511 could be…
I got bit by this using the Emacs package manager. It follows redirects, so it ended up trying to fetch a package and getting back a bunch of HTML with a 200 response code, which it tried to byte-compile with about as spectacular a failure as you would imagine.
Earlier quoted context omitted.
Google is trying: http://www.chromium.org/spdy
SPDY isn't really intended to replace HTTP I don't think, it's just speeding it up quite a bit. All the messages exchanged between client and server are still HTTP when using SPDY.
Earlier quoted context omitted.
SPDY isn't really intended to replace HTTP I don't think, it's just speeding it up quite a bit. All the messages exchanged between client and server are still HTTP when using SPDY.
No, SPDY replaces HTTP but keeps many of the same high-level semantics. The messages are not HTTP; for example, the headers are a binary format and compressed which isn't possible with HTTP.
Isn't this something that the http server handles? I am not in web development except for basic php and cgi scripts. Are people actually writing web app code to dictate what http code comes back on each request?
Yes, sometimes the correct response is not an HTML page, but an error code (e.g. 301 Moved Permanently, 302 Found are used to implement redirects).
OMG really? Do we want to make HTTP even bigger? Don't we want to dump it for good and look for something more suitable to what the modern web needs instead?
More codes - which, by the way, do not increase the size of the packets - are better for the "modern web", the one where REST APIs are being adopted and which has more and more automated clients which require computer readable information.
Earlier quoted context omitted.
No, SPDY replaces HTTP but keeps many of the same high-level semantics. The messages are not HTTP; for example, the headers are a binary format and compressed which isn't possible with HTTP.
Well technically HTTP as an application-layer protocol is unchanged. So I don't really understand your comment. The messages are HTTP. Whether the headers are compressed by an underlying protocol (such as SPDY) doesn't seem to be relevant.
For example, although SPDY supports HTTP methods (GET, POST, PUT) the method and parameters are specified as headers in the request. Also, all the header names are lower-cased in SPDY. The client and server don't communicate by a single stream as in HTTP but instead communicate in frames over the stream that can contain multiplexed requests and responses.
At the very high level, you might be able to build an API that could handle web requests and responses over HTTP or SPDY interchangeably but that API isn't "HTTP".