Earlier quoted context omitted.
511 is aimed for the wifi networks that you find in hotels & airports where you have to pay money for access, or create an account.
Indeed. It will be very nice to not return a 403.
How about 402 Payment Required?
New HTTP Codes
71–80 of 84 posts
Re: New HTTP Codes
#72Earlier quoted context omitted.
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.
An application layer protocol is the layer above TCP and defines the formats of those messages over that transport. Other application layer protocols are, for example, FTP, DNS, and SMTP. SPDY and HTTP have completely different (and incompatible) message formats even though they are meant for the same task. And it isn't HTTP tunneled through SPDY; there are significant differences. For example, although SPDY supports…
I don't really want to argue about the semantics of OSI and what is or isn't an application layer protocol. I'll just point you to Google's own diagram of where SPDY fits in which is in the "SPDY design and features" section of the whitepaper here: http://www.chromium.org/spdy/spdy-whitepaper.
Here's the text from that section:
"SPDY adds a session layer atop of SSL that allows for multiple concurrent, interleaved streams over a single TCP connection.
"The usual HTTP GET and POST message formats remain the same; however, SPDY specifies a new framing format for encoding and transmitting the data over the wire."
Re: New HTTP Codes
#73Earlier quoted context omitted.
503 seems the most appropriate of the current codes ("The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay.")
Twitter uses "420 Enhance Your Calm" (...) A new error code is definitely needed.
This made me lol...literally!
Re: New HTTP Codes
#74Re: New HTTP Codes
#75Earlier quoted context omitted.
An application layer protocol is the layer above TCP and defines the formats of those messages over that transport. Other application layer protocols are, for example, FTP, DNS, and SMTP. SPDY and HTTP have completely different (and incompatible) message formats even though they are meant for the same task. And it isn't HTTP tunneled through SPDY; there are significant differences. For example, although SPDY supports…
I don't really want to argue about the semantics of OSI and what is or isn't an application layer protocol. I'll just point you to Google's own diagram of where SPDY fits in which is in the "SPDY design and features" section of the whitepaper here: http://www.chromium.org/spdy/spdy-whitepaper . Here's the text from that section: "SPDY adds a session layer atop of SSL that allows for multiple concurrent, interleaved s…
That is an old (and obviously inaccurate) summary. You can read the protocol document here:
http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-dra...
Check out the "Main differences from HTTP" section. It's clearly not the same format as HTTP. Whatever they mean by "GET and POST message formats remain the same" it's not what you're thinking it means.
There's no confusion about the "semantics of OSI" -- you can't take a client that talks only HTTP and get it talk to a server that talks only SPDY (and vice-versa). They are different application level protocols, period.
Re: New HTTP Codes
#76429 looks to me as if it might be addressing aggressive http pipelining, but I was under the impression that most browsers have pipelining turned off.
Both Firefox and opera offer pipelining while it is deactivated on chrome (next release will have it on by default).
Re: New HTTP Codes
#77Earlier quoted context omitted.
I don't really want to argue about the semantics of OSI and what is or isn't an application layer protocol. I'll just point you to Google's own diagram of where SPDY fits in which is in the "SPDY design and features" section of the whitepaper here: http://www.chromium.org/spdy/spdy-whitepaper . Here's the text from that section: "SPDY adds a session layer atop of SSL that allows for multiple concurrent, interleaved s…
That is an old (and obviously inaccurate) summary. You can read the protocol document here: http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-dra... Check out the "Main differences from HTTP" section. It's clearly not the same format as HTTP. Whatever they mean by "GET and POST message formats remain the same" it's not what you're thinking it means. There's no confusion about the "semantics of OSI" -- you can'…
The "Main differences from HTTP" section says this:
"SPDY is intended to be as compatible as possible with current web-based applications. This means that, from the perspective of the server business logic or application API, nothing has changed. To achieve this, all of the application request and response header semantics are preserved. SPDY introduces a "session" which resides between the HTTP application layer and the TCP transport to regulate the flow of data."
This even explicitly says that SPDY resides underneath the HTTP application layer.
So from the point of view of e.g. GMail, it is making HTTP requests via XmlHttpRequest still is it not? And from the point of view of my Django application sitting behind some future apache/nginx SPDY module I will still be accepting HTTP requests and responding with HTTP responses will I not?
It seems like SPDY sits in the same layer as SSL/TLS in HTTPS. It doesn't replace HTTP, merely changes how the messages are transported over the wire. To use your logic, you can't point an HTTPS-only client at an HTTP server and have it work or vice-versa, and yet I quote from wikipedia:
"HTTP operates at the highest layer of the OSI Model, the Application layer; but the security protocol operates at a lower sublayer, encrypting an HTTP message prior to transmission and decrypting a message upon arrival. Strictly speaking, HTTPS is not a separate protocol, but refers to use of ordinary HTTP over an encrypted SSL/TLS connection."
Re: New HTTP Codes
#78Re: New HTTP Codes
#79Earlier quoted context omitted.
That is an old (and obviously inaccurate) summary. You can read the protocol document here: http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-dra... Check out the "Main differences from HTTP" section. It's clearly not the same format as HTTP. Whatever they mean by "GET and POST message formats remain the same" it's not what you're thinking it means. There's no confusion about the "semantics of OSI" -- you can'…
The "Main differences from HTTP" section says this: "SPDY is intended to be as compatible as possible with current web-based applications. This means that, from the perspective of the server business logic or application API, nothing has changed. To achieve this, all of the application request and response header semantics are preserved. SPDY introduces a "session" which resides between the HTTP application layer and…
> So from the point of view of e.g. GMail, it is making HTTP requests via XmlHttpRequest still is it not?
No, it's making SDPY requests. It is, however, making that difference insignificant to the application developer using the xmlHttpRequest API. HTTP is a protocol not an API. This is exactly what the paper says; the protocol is designed to make the API differences very minimal.
> And from the point of view of my Django application sitting behind some future apache/nginx SPDY module I will still be accepting HTTP requests and responding with HTTP responses will I not?
No, Django doesn't talk HTTP -- Django talks WSGI or CGI. That hides many of the details of the protocol in use -- I imagine that you could run Django with a server that sends/receives web requests over FTP. That doesn't make FTP into HTTP.
SPDY does not sit in the same level as SSL. With SSL, HTTP packets are tunneled through it. SDPY replaces HTTP; there is no fully formed HTTP message inside. If SPDY was merely multiplexing and compressing HTTP streams in frames, I would agree that it would be like HTTPS. But SPDY doesn't contain HTTP streams; it's all right there in the document.
Re: New HTTP Codes
#80A 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.
You have different tools to write RFC-like documents. One of the most common one used is xml2rfc (http://xml.resource.org/) but there is also rst2rfc (http://code.google.com/p/rst2rfc/).