Subject: Re: idempotence of POST

From: Dave Oxley <[email-masked]>
Date: Thu, 20 Nov 2003 12:48:04 -0500 (EST)

http://lists.w3.org/Archives/Public/ietf-http-wg-old/1996SepDec/0059.html

This was a message from '96 that I found with a Google search. Was this 
ever implemented and how? If not, is there another way to achieve this?

   a) allow GET to take a body
   b) add a new method, GET-with-body (spelled how you like)
   c) allow the return value of POST to indicate that the request
      can be repeated safely.

Please reply off list as I'm not subscribed. Cheers.
Dave.

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Sat, 22 Nov 2003 17:35:21 +0100

Dave,

I'm not aware of any such implementation.

Perhaps you can make it work with the URL parameters.
Much like search engines do.

Having POST/PUT idempotence would be imcompatible with many applications
(and the protocol itself).

- Joris

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dave Oxley
> Sent: Thursday, 20 November 2003 18:48
> To: [email-masked]
> Subject: Re: idempotence of POST
> 
> 
> 
> 
>
<http://lists.w3.org/Archives/Public/ietf-http-wg-old/1996SepDec/0059.html>
> 
> This was a message from '96 that I found with a Google 
> search. Was this ever implemented and how? If not, is there 
> another way to achieve this?
> 
> This e-mail has been scanned for all viruses by Star 
> Internet. The service is powered by MessageLabs. For more 
> information on a proactive anti-virus service working around 
> the clock, around the globe, visit:
> http://www.star.net.uk

---

From: Mark Baker <[email-masked]>
Date: Mon, 24 Nov 2003 20:37:04 -0500

Since '96, several protocols have been developed which can be used to
extend HTTP so that you could build an idempotent POST; PEP, RFC 2774,
and SOAP.  So that's one possible approach.

More comments below ...

>    a) allow GET to take a body

GET is a different operation to POST, and means something quite
incompatible with it.  Except in very specific cases, I don't think
that's what you'd want to do.

If none of the above extension protocols are an option, I'd suggest
that you should consider how to wrangle your request to use PUT, which
takes a body and is idempotent.  Perhaps the server could return a URI
to which a PUT would be performed?

>    b) add a new method, GET-with-body (spelled how you like)

Same issues with GET semantics.

>    c) allow the return value of POST to indicate that the request

In my experience, an idempotent POST is most desirable in the situation
where a response is not, or may not be, available.  So signally it in
a response after the fact seems nonsensical.  But perhaps there are
other use cases I'm not familiar with.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

---

From: David Morris <[email-masked]>
Date: Mon, 24 Nov 2003 17:37:55 -0800 (PST)

> other use cases I'm not familiar with.

Actually, idempotence is of no interest if a prior response doesn't exist
.. or more precisely .. knowledge of a prior request doesn't exist. If the
user-agent has no such knowledge, then idempotence isn't an issue for GET
or POST.

The SAFE protocol proposal allowed a server to signal that a particular
POST was itempotent and could be re-issued w/o user prompting with no
risk of data distortion. It also logically means that a user-agent didn't
have to submit the POST request to the server if it had a valid cached
response.

Safe POST was the best alternative we could conceive of for allowing a
logical GET w/body which is a desirable feature. For example:
a. There is an expectation of a finite length for URLs ... allowing a body
would have resolved those issues
b. In some application interactions, such as login, it is quite
undesirable to have the credential data included in a URL ...
 i. They tend to be easy to compromise on the user's workstation through
    interfaces such as the broser location field.
 ii. Encoded URLs usually appear in server log data ... in order
    to preclude such exposure applications tend to use POST
    requests which may not be needed otherwise
Etc.

Dave Morris

---

From: "Charumathy Venkatraman" <[email-masked]>
Date: Tue, 25 Nov 2003 09:35:47 +0530

Hi,

I hope this is not too much off topic, but I am currently testing my HTTP
client with Microsoft IIS server. Every time I issue a POST request I get
Error 405 (Method not allowed) along with an Allow response header that does
not list POST in the list of allowed methods.
We have tried to configure the server in several different ways - we allowed
all methods for the directory to which I am POSTing, but there is no change
in behavior.
Can anyone shed some light on this?

Thanks,
Charu.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 25 Nov 2003 08:43:12 -0700 (MST)

On Tue, 25 Nov 2003, Charumathy Venkatraman wrote:

> I hope this is not too much off topic, but I am currently testing my
> HTTP client with Microsoft IIS server. Every time I issue a POST
> request I get Error 405 (Method not allowed) along with an Allow
> response header that does not list POST in the list of allowed
> methods. We have tried to configure the server in several different
> ways - we allowed all methods for the directory to which I am
> POSTing, but there is no change in behavior. Can anyone shed some
> light on this?

I do not use MS IIS, but it sounds like you may be missing the
application on the server end to accept (do something with) POSTs. On
general-purpose web servers, one cannot POST to a directory or a file;
there has to be a program (e.g., a CGI script) on the server side for
processing of POST requests.

Alex.

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Tue, 25 Nov 2003 23:30:34 +0100

Charu, 

If you are using IIS 6.0 (with Win2003), these things are turned off by
default. You need to turn them on.
Check for the URLScan configuration, if installed (needs to be done
manually). Check whether ASP and such are actually running.

Please refer to the Windows or IIS help or MS web site (knowledge base) for
information. You can also try a Microsft newsgroup regarding IIS, they will
probably know these kind of things.

- Joris

> [mailto:[email-masked]] On Behalf Of Charumathy 
> Venkatraman
> Sent: Tuesday, 25 November 2003 5:06
> To: [email-masked]
> Cc: [email-masked]
> Subject: Support for POST
> 
> 
> Hi,
> 
> I hope this is not too much off topic, but I am currently 
> testing my HTTP client with Microsoft IIS server. Every time 
> I issue a POST request I get Error 405 (Method not allowed) 
> along with an Allow response header that does not list POST 
> in the list of allowed methods.
> We have tried to configure the server in several different 
> POSTing, but there is no change in behavior.