POST alters data, never retrieves it.

Except for all of the cases where POST returns data, sure. There is absolutely no reason to destroy the result of creating a resource instead of returning the newly created resource with a flag "don't do that again".

You are using a perfectly good axe as a door stop then whining that your teaspoon isn't cutting down trees properly.

Meanwhile you're dulling the perfectly good axe to be sure that nobody cuts down your sacred tree.

With modern frameworks and Java level classiness (here, have a mappingfactory class that instantiates the mapping class that maps the data from the form into the object returned from the factory class that produced the object being created) what happens is more like

The POST creates a hospital, staffs it with receptionists, doctors, nurses, and so on. A pregnant woman (the request) goes in, the receptionist routes her to the OB ward where nurses help her into the stirrups and the doctor catches the baby. The doctor takes all the baby's stats, writes it on the birth certificate, drops the certificate into a pneumatic chute that whisks it away to safety (in the database) as the hospital and all its occupants are immediately vaporized by an explosion (if you're still using CGI, replace this with the entire sun going supernova. Add recreating the solar system to the beginning of the next request).

The GET creates a hospital, staffs it with receptionists, doctors, cloning technicians, and so on. A woman (the request) goes in, the receptionist routes her to the cloning ward where the woman hands over the birth certificate that had been mailed to her, the doctor looks over the certificate and checks to make sure she's really supposed to have it (or not, given the state of security these days) then pulls out a cloning tank and reconstitutes a baby that is identical in every way (ideally) to the original and hands it to the woman. As the woman leaves the hospital baby in tow, it explodes behind her, action movie style.

Or, y'know, you could just pass the new baby straight to a View and do all this with half the hospitals, doctors, receptionists and none of the cloning vats.

then I've got a 486 upgrade I'll donate for free.

Thanks! Once it can do the same task with half the number of requests, it'll work twice as well!

I think this is less a problem with the HTTP protocol

Using onload="history.pushState(null, null, '/user/31813812');" certainly works, but now pushing the "back" button is the landmine instead of pushing refresh (not to mention users that turn off javascript). Being able to use javascript to pretend you're doing what the HTTP procotol should have done does not make it not a problem with the protocol.

That said, the HTTP/1.1 protocol itself is fine. A user agent ought handle a 201 Created response exactly like this as a side effect (OK, so the response body is technically not a listing of places you can get the created object from, but it's supposed to be displayed to the user either way), but there are zero browsers implementing the Location part of it. Adding a response code explicitly for the purpose of "here is a response to display to the user right now, if the user wants to reload it, request this URL instead" would hopefully get browser developers to say "oh, I see why we're doing this" and do it. Doubly so when they're writing a new implementation for a new protocol. At this point, I'd argue that the best thing to do would be to add something like "311 Content With Future Redirect" so that browsers that don't implement it continue with 3xx POST-Redirect-GET semantics (losing nothing) and browsers that do understand it will work.

Will HTTP/2 have a response code that will cause the browser to display the page that is returned from the server AND change the "current url" (for bookmarking, refreshing etc) to an alternate Location? POST to /createnewuser, display the response immediately with the URL of /user/3813812. Refreshing loads /user/3813812, not re-POSTing to /createnewuser.

Right now, the current paradigm of having to either redirect every single POST request to a new URL or risking users too stupid to know that they really need to not press reload on the page after saving something is a drain on server resources one way and support resources the other.

Invest in my scheme! Send me money and I'll send you slips of paper that say you own gold!

You'll have the choice of paying extra for Windows 366 on those years, or else leaving your computer off for an entire day.

before you get hit with the federal whammy?

Cmon big bucks no whammys no whammys...

Currently the velocity of railguns is roughly equivalent to navel guns.

I dunno, some navel guns are pretty powerful.

I think you mean /* Insightful */

Maybe he was going for imp -> impious than for im-pious.

It's hard to say. To be honest, to me they sound exactly like the non-answers I'd expect any executive officer to give. The fact they don't mention PRISM at all in reference to recent US government capability is definitely interesting, given that they used to openly state that TOR is weak against such widespread surveillance.

Does having a Netflix server in Comcast's data center cause Comcast to slow down Hulu? If so, Comcast probably ought to fix that. If not, then how is it prioritized?

A way to protect or extend your telomeres might be the only vaccine for death.

HeLa certainly appreciates it.

4428 1/3 B 43rd 1/2 NE St.

And attaching a brand name makes it any different? What makes Centrum better than CVS?