4 ms·

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

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.

fanf2 11y ago
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.
- spacecowboy_lon 11y ago
  why if you stuff up a 301 you just implement a new set - search engines ignore 302's
  - nitrogen 11y ago
    Browsers can cache a 301
spacecowboy_lon 11y ago
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.
- BillinghamJ 11y ago
  They're not non-standard, and any unrecognized 3xx codes are treated as 300.
  - spacecowboy_lon 11y ago
    And you know exactly how google, bing et al handle this situation.
- voltagex_ 11y ago
  Isn't 301 a permanent redirect (and will be cached as such) and 302 is temporary?
  - andreineculau 11y ago
    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/status-codes.md#3xx https://github.com/for-GET/know-your-http-well/blob/master/s...
    - spacecowboy_lon 11y ago
      err No a temporary redirect is not the same as a permmenat one
seanp2k2 11y ago
Not to mention the case where traffic can be cached by a proxy which sits behind where SSL is terminated.
oneeyedpigeon 11y ago
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?
- ErrantX 11y ago
  https://en.wikipedia.org/wiki/HTTP_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....
- bkeroack 11y ago
  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.go#L362-L364 https://github.com/golang/go/blob/master/src/net/http/client... 2. https://github.com/golang/go/issues/9348#issuecomment-86790338 https://github.com/golang/go/issues/9348#issuecomment-867903...
e12e 11y ago
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.
- nitrogen 11y ago
  That's what CDNs are for.

fanf2 11y ago

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.

spacecowboy_lon 11y ago
why if you stuff up a 301 you just implement a new set - search engines ignore 302's
- nitrogen 11y ago
  Browsers can cache a 301

spacecowboy_lon 11y ago

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.

BillinghamJ 11y ago
They're not non-standard, and any unrecognized 3xx codes are treated as 300.
- spacecowboy_lon 11y ago
  And you know exactly how google, bing et al handle this situation.
voltagex_ 11y ago
Isn't 301 a permanent redirect (and will be cached as such) and 302 is temporary?
- andreineculau 11y ago
  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/status-codes.md#3xx https://github.com/for-GET/know-your-http-well/blob/master/s...
  - spacecowboy_lon 11y ago
    err No a temporary redirect is not the same as a permmenat one

seanp2k2 11y ago

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

oneeyedpigeon 11y ago

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?

ErrantX 11y ago
https://en.wikipedia.org/wiki/HTTP_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....
bkeroack 11y ago
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.go#L362-L364 https://github.com/golang/go/blob/master/src/net/http/client... 2. https://github.com/golang/go/issues/9348#issuecomment-86790338 https://github.com/golang/go/issues/9348#issuecomment-867903...

e12e 11y ago

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.

nitrogen 11y ago
That's what CDNs are for.