Live data from Hacker News

New HTTP Codes

tools.ietf.org

11–20 of 84 posts

Re: New HTTP Codes

#11

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.

Nothing special, it`s just your browser's default monospaced font.

Re: New HTTP Codes

#12

511 seems a little pointless -- browsers can treat it differently, but if the intermediate gateway intends to be malicious, then it won't return 511 anyway. The only useful thing I can see is avoiding accidents/attacks on the gateway compromising its clients.

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.

Re: New HTTP Codes

#13

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.

It was created using rfcmarkup[1], a tool made by the ietf. A quick look at the source of the page in the "generator" meta tag would have told you that (that's how I just found out) :-).

[1] https://tools.ietf.org/tools/rfcmarkup/

Re: New HTTP Codes

#14

511 seems a little pointless -- browsers can treat it differently, but if the intermediate gateway intends to be malicious, then it won't return 511 anyway. The only useful thing I can see is avoiding accidents/attacks on the gateway compromising its clients.

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

Re: New HTTP Codes

#16
post #12

511 seems a little pointless -- browsers can treat it differently, but if the intermediate gateway intends to be malicious, then it won't return 511 anyway. The only useful thing I can see is avoiding accidents/attacks on the gateway compromising its clients.

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.

Re: New HTTP Codes

#17

These all seem immediately practical status codes that add semantics I've been wanting. Great! In particular I am happy about the 429 Too Many Requests header, as every time I've done rate throttling I've had to quibble over what code to actually send back.

[deleted]

Re: New HTTP Codes

#18

511 seems a little pointless -- browsers can treat it differently, but if the intermediate gateway intends to be malicious, then it won't return 511 anyway. The only useful thing I can see is avoiding accidents/attacks on the gateway compromising its clients.

I don't think 511 is so much for security, I see it as being more focused on usability. For example if you have thick client program that talks to a backend server (perhaps for updates) and it receives a 511 response it can then tell the user that they need to login to the proxy (or just pop up a web browser for them).

Exactly: a good example is how OS X currently works - everytime you connect to a new WiFi hotspot it fires a request to a static page on Apple's server in the background, to determine whether or not you have to sign in. If it detects unexpected content it assumes it's a sign-in page for a WiFi hotspot, and presents it modally.

Under this proposed system the OS can simply check for an appropriate HTTP response code, which makes life a little easier.

Re: New HTTP Codes

#19
post #8
post #4

I wish HTTP requests submitted time zone information.

Just the current offset from UTC, or including the whole daylight savings malarkey?

The actual Timezone would be great (something like Europe/London, etc.) Using the same format as the tz database: http://en.wikipedia.org/wiki/Tz_database#Names_of_time_zones

Re: New HTTP Codes

#20
post #8

Earlier quoted context omitted.

Just the current offset from UTC, or including the whole daylight savings malarkey?

The actual Timezone would be great (something like Europe/London, etc.) Using the same format as the tz database: http://en.wikipedia.org/wiki/Tz_database#Names_of_time_zones

I suppose now ICANN maintain it, it makes it easier for it to become an internet standard.
Post reply on HN