Suppose that you're on website B and it wants to send a large chunk of information to some endpoint on website A, through your browser. If this was a small amount of information, website B could use a HTTP redirect with the information stuffed into one or more query parameters. However, HTTP GET query parameters have a size limit and sometimes you have an especially verbose chunk of information to transfer. Enter what I've now seen called the "HTTP self-post". In a HTTP self-post, website B serves your browser a HTML page with a pre-filled POST form pointing to the endpoint on website A, and adds some Javascript to the page to immediately submit the form when the page loads.

(The page's HTML can have a little message telling you to 'Submit' things in case you have Javascript off.)

In one view, this is pretty close to cross-site request forgery and can only be told apart from it based on intent, which the browser can't really observe. In another view, this is essentially a POST based HTTP redirect, done through HTML and Javascript only because HTTP explicitly has no such thing (for good reasons). Of course, both views can be true at once.

You might ask, as I did when I read about this today, why website B doesn't make its own POST request to website A's endpoint instead of relaying its block of information through your browser. One reason is that website B may not be able to communicate directly with website A. Website B might be your corporate single sign on portal while website A is an internal web server inside your group's internal networks.

Another reason is that your browser may have to go back to website A anyway and coordinate with the information that website B is delivering to A. Again, consider SSO. Your browser has to return to website A to use it (and perhaps to be authorized), but website A needs to have the information from website B before it can do anything with you. It's simpler and more reliable to bolt these two things together, so that either you wind up on website A with it having all of the information necessary to move forward (in theory) or you go nowhere.

(In this scenario you visited website A as an unidentified and unauthenticated person and it sent you to website B to get identified. Your browser is the only thing guaranteed to be able to reach both websites, because if you can't reach one or the other nothing works.)

Hopefully I will never need to build a web system that uses HTTP self-post(ing), but at least now my ideas of how things can be done with HTTP have been expanded a bit. And if I do build such a system, I will have to carefully consider how to shield it from CSRF, since the two are so close to each other.

(This elaborates on a tweet of mine, which was written while I was slowly reading my way through the mod_auth_mellon user guide.)