Comments on: Double POST and POE

By: subbu

subbu — Sun, 18 Jan 2009 03:53:35 +0000

I see. If you are writing the app for browsers, then the most common solution is anyway to include hidden form parameters, and do a 303 to the same page. When that page is regenerated, the server can include a different hidden parameter in the form. But it looks like you may be writing a specialized app.

By: mcm

mcm — Mon, 12 Jan 2009 12:05:37 +0000

I agree when talking about an HTTP library as the client.

But I was talking about the user client. I don’t want the user to be asked if a POE redirect should be followed. This problem occurs when the actual http library is supplied by the browser (like in ajax or xul apps; e.g. XmlHttpRequest). At least Firefox/XulRunner handle the 307 automatically and ask the user for confirmation. I couldn’t find a way to override that behaviour.

That’s why I’m using a modified version of the original POE draft instead. Only modified it to exchange all poe related information in special, non-standard headers, instead of encoding it in the URI (because this was easier to implement in my case).

By: subbu

subbu — Mon, 12 Jan 2009 02:59:49 +0000

The use of 307 is intentional here. We don’t want the client to automatically follow such a redirect.

By: mcm

mcm — Tue, 16 Dec 2008 11:19:54 +0000

Thanks for this interesting idea. Might be fine for custom clients but will probably not work to well with standard browsers. RFC 2616 states:

If the 307 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.

And at least the current Firefox (3.0.4) asks for user confirmation on POST redirect (also when specifying a local/relative redirect location).

Since I am looking for a solution that works for my custom written client and for ordinary web browsers, I’ll stay with the original POE draft and use the special POE headers defined in there. That will enable POE only for my custom client (since it requires custom request handling), but at least it won’t break standard web browsers (since my server will still accept ordinary POST requests without POE header).

Any better suggestions?

By: subbu

subbu — Sun, 12 Oct 2008 00:56:51 +0000

Thanks

This POE pattern does not require the server to determine if two given POST requests contained the same data. So it can fail fast.

In some cases, the fact that the request contained the same data may not necessarily mean that they are duplicate requests. Say, e.g. two requests to Twitter with the same data by the same user.

But if the server can determine that they are the same, and it also remembers the resource that was created the first time, instead of returning a 409, it can return a 303 (See Other) with the Location of that resource. That is, there is no need to fail the request in this case. If not, it can return a 405 (which I think is more appropriate than 409).

By: James Franz

James Franz — Sat, 11 Oct 2008 23:33:12 +0000

First off great post, keep up the good work, this is one of my favorite blogs.

I just wanted to throw out a idea, why not take a hash of the POST request data (or a subset of it, whatever determines uniqueness) and store it on the server to match with the success of the POST. This would be the “transaction id” of sorts. If a client then submits a duplicate POST, the hash would match and you’d throw a 409? error.

By using a hash of the POST variables, you could even choose the variables that make the POST unique. If what we are trying to prevent is duplicate POST transactions, what easier way would there be other than comparing the data sent in the POST request?

What am I missing?