Some things I don&#x27;t particularly like in this diagram:<p>* I don&#x27;t consider 307 and 308 to be irrelevant. Even if many browsers today are safe against method-change attacks, it&#x27;s always better to be explicit.<p>* I don&#x27;t see why 304 would only be used if &quot;implementing a web server&quot;. Many web applications do their own Last-Modified or E-Tag checking behind the web server (and for good reason).<p>* There are also non-webserver reasons you&#x27;d use 408 and 413.<p>Also<p><pre><code>    &gt; I don’t find this argument compelling, if for no other 
    &gt; reason than this: in a world where everyone is moving
    &gt; to HTTPS, we’ve forbidden any proxy or caching nodes 
    &gt; that are not under direct control of the server.
</code></pre>
What? Even if you are controlling the cache, I don&#x27;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&#x27;t have direct control of your proxy cache, but are still using HTTPS.)<p>Otherwise I&#x27;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.