Arbitrarily changing a POST to a GET can also end up in your customers
ordering two sets of football tickets, rather than one.
A repeat of a POST requires that the user be prompted, as POSTs are
non-idempotent. Browsers can issue as many GET requests as they like in
order to get the page downloaded (IE, for example, appears to just repeat a
GET request if looks like the first attempt is taking too long).
And as Neale says, having things like credit card numbers, passwords, etc.,
in your browser history isn't ideal.
Finally, here's what HTTP/1.1 has to say on URI lengths:
The HTTP protocol does not place any a priori limit on the length of
a URI. Servers MUST be able to handle the URI of any resource they
serve, and SHOULD be able to handle URIs of unbounded length if they
provide GET-based forms that could generate such URIs. A server
SHOULD return 414 (Request-URI Too Long) status if a URI is longer
than the server can handle (see section 10.4.15).
Note: Servers ought to be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy
implementations might not properly support these lengths.
(from 3.2.1, General Syntax).
We've run into a number of problems in the past in which application servers
have transformed POSTs into GETs for their own internal reasons (usually to
munge things into some MVC-esque structure), and dissappeared parameters off
the end of the list. Very frustrating, and very tedious to debug :(
Dan.
> -----Original Message-----
> From: Neale [mailto:[EMAIL PROTECTED]]
> Sent: 07 February 2003 09:01
> To: Tomcat Users List
> Subject: Re: response.sendRedirect() - is this allowed?
>
>
> > >if ( "POST".equalsIgnoreCase( request.getMethod() ) )
> > >{
> > > StringBuffer buf = new StringBuffer();
> > > buf.append( request.getRequestURI() );
> > > buf.append( "?" );
> > > buf.append( request.getQueryString() );
> > > response.sendRedirect( buf.toString() );
> > > return;
> > >}
>
> You need to be careful doing this actually... While it will work in most
> cases,
> if the data + URL is longer than 2048 bytes it will fail (for
> RFC-compliant
> browsers) as 2048 bytes is the limit on GET. In this case data will be
> truncated
> after 2048 bytes and there is a risk of crashes or incorrect data
> being sent
> to the process-function. GET also exposes all the arguments on
> the URL line
> which can be messy and dangerous if the form contained sensitive
> information.
>
> If the data length + URL length is longer than 2048 bytes, or to stop
> double-posts,
> use the following method, which is sometimes called "POST-cleaning":
>
> - Use POST as the method
> - When the servlet/JSP processes the POST, first check the data
> and display
> error messages for missing-data etc.. (data-validation).
> - If there are no errors, *do not* output anything, just process the data.
> - After processing, use sendRedirect() to send the user to a page that
> displays
> the output (eg: Thankyou for your submission, or Update
> successful, or send
> them back to the menu etc..). Now the final page is retrieved with a GET,
> has no 2k-limit on the data for thr processing, and has no displayed URL
> params.
> - Instead of setting sendRedirect(), also consider using
> setHeader calls to
> set the status
> to 302 with the new location, and also output a meta-refresh tag
> which sends
> the
> user to the final page and/or some javascript which sends them to
> the final
> page
> (or at worst a link saying click here to continue). Now you have
> 4 methods
> to
> make sure they continue to the result-page instead of relying on the 302.
> - Use sessions or a URL token to maintain the state, because after
> sendRedirect(),
> the servlet will be called again with a GET, and you will need some way to
> figure
> out who the client is and what data was submitted in case you need to
> display it
> again.
>
> Hope that helps,
> Neale Rudd
> metawerx java hosting
> http://www.metawerx.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
