Comment by parent5446 | Hacker News Reader

Comment by parent5446 | Hacker News Reader

Some things I don't particularly like in this diagram:

* I don't consider 307 and 308 to be irrelevant. Even if many browsers today are safe against method-change attacks, it's always better to be explicit.

* I don't see why 304 would only be used if "implementing a web server". Many web applications do their own Last-Modified or E-Tag checking behind the web server (and for good reason).

* There are also non-webserver reasons you'd use 408 and 413.

Also

    > I don’t find this argument compelling, if for no other 
    > reason than this: in a world where everyone is moving
    > to HTTPS, we’ve forbidden any proxy or caching nodes 
    > that are not under direct control of the server.

What? Even if you are controlling the cache, I don't see why you would want to make your job more difficult by having to explicitly control it when HTTP can do much of the job for you. (Not to mention there are cases, specifically AWS and cloud services, where you wouldn't have direct control of your proxy cache, but are still using HTTPS.)

Otherwise I'm glad to see some people still think using a variety of HTTP status codes appropriately is a good idea. It makes services easier to use and more intuitive.

Also, permanent redirects need a big caveat: if you screw them up you will have a bad day, because they are nearly impossible to fix - browsers take "permanent" literally. Better to use temporary redirects with sensible but limited lifetime.

why if you stuff up a 301 you just implement a new set - search engines ignore 302's

Browsers can cache a 301

Doesn't HTTPS explicitly support an intercepting, deep-inspecting, proxy? So if I want to reduce bandwidth at my site - or scan for malware, I can install a SSL-certificate my clients trust, and proxy the HTTPS connections, with eg. squid? Just because there are many nefarious uses of an SSL proxy/mitm, doesn't mean that there aren't good uses for it too?

As bandwidth to even home users go up, the need for local caching proxies might go down -- but at the same time, Netflix is an example of how the current architecture of the Internet isn't enough if you want to do individual media streaming (they maintain their own caches, but that just means that if one wanted to distribute a few TB of hd video, say an independent documentary series, or even a video diary, one might expect to either have to pay a high bandwidth bill, or do some "proximity caching"). Alternatives exist of course, such as using a torrent for distribution -- but throwing out all ideas of content proxying "beacause TLS" seems misguided.

That's what CDNs are for.

Don't get clever and use these wacky non standard status codes like 307 308 303 your at the mercy of Google as to how they will treat them.

99.9% of the time use a 301 redirect.

They're not non-standard, and any unrecognized 3xx codes are treated as 300.

And you know exactly how google, bing et al handle this situation.

Isn't 301 a permanent redirect (and will be cached as such) and 302 is temporary?

Yes and no. 302 allow the user-agent to change the HTTP method to GET. 307 is the temporary redirect, equivalent to the permanent 301.

https://github.com/for-GET/know-your-http-well/blob/master/s...

err No a temporary redirect is not the same as a permmenat one

I'd be interested in the use case where the difference between 302 and 307:

  the user agent MUST NOT change the request method if it performs
  an automatic redirection to that URI

is significant. Do user agents switch from POST to GET when following a 302?

https://en.wikipedia.org/wiki/HTTP_302

Most browsers mis-implement 302; hence 303 (must change to GET) and 307 (must persist request method) were added to make the options explicit.

Of course, just because a standard now exists....

The Go standard library HTTP client (net/http) changes POST/PUT redirects to GET[1] and it's super annoying.

EDIT: Here's the rationale (from [2]):

"I think the underlying principle of the matter is that if the client is going to resend the POST request body data, then RFC 2616 wants clients to get the user's consent. The trouble is that most client implementations did not resend the POST data when following 301 or 302 redirects. So the principle of getting user consent doesn't really apply.

RFC 7231 (HTTP/1.1 June 2014) changes this. It ratifies the common behavior of 301 and 302 (to not re-POST), and in doing so it leaves it up to the client to determine when it is safe to automatically redirect."

1. https://github.com/golang/go/blob/master/src/net/http/client...

2. https://github.com/golang/go/issues/9348#issuecomment-867903...

Not to mention the case where traffic can be cached by a proxy which sits behind where SSL is terminated.

Reply on news.ycombinator.com