Live data from Hacker News

New HTTP Codes

tools.ietf.org

31–40 of 84 posts

Re: New HTTP Codes

#33
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?

Re: New HTTP Codes

#34
post #32

Shouldn't 429 (Too many requests) be a 5xx code?

I think it's fine. 4xx is a way of saying the client did something wrong that it can potentially fix (i.e. slow down requests). 5xx is more opaque meaning there is nothing the client can do to fix the problem.

Re: New HTTP Codes

#36
post #25
post #5

Summary: 428 Precondition Required 429 Too Many Requests 431 Request Header Fields Too Large 511 Network Authentication Required I've been using 414 Request-URI Too Long for 431 and 503 Service Temporarily Unavailable for 429

Apart from the obvious semantics, what's the difference between 428 and 412? (412 - precondition failed)

AFAICS, 412 is only meaningful when the request did specify a precondition (which failed), while 428 means that the request didn't specify some precondition (which was required by server).

Re: New HTTP Codes

#37

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?

What do you propose we do in he meantime, before all the existing servers and clients are migrated?

Re: New HTTP Codes

#38
511: 'Unknown clients then have all traffic blocked, except for that on TCP port 80, which is sent to a HTTP server (the "login server") dedicated to "logging in" unknown clients, and of course traffic to the login server itself.'

Ugh. Couldn't this be more generic?

Re: New HTTP Codes

#40

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?

Rewriting a large and complex enterprise-class application is tough enough, and a task that can variously (and expensively) fail.

Rewriting the whole of the World Wide Web?

Your replacement had better have a solid compatibility and migration path with "legacy" HTTP, and provide a substantial improvement over what HTTP and the existing tools provides, and clients and a migration path for a majority of the platforms and tools and browsers and embedded browsers and embedded web servers in use, and the budget and the time to make the replacement push.

Post reply on HN