Thanks Jerry,
At 29/04/01 14:26, you wrote:
>Steve,
>
>I think what you are asking is pretty much outlawed in RFC 2616, the
>HTTP/1.1
>specification.
>http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3
>
>(Although it also looks as though the AOLserver is not up to spec either:
>ns_returnredirect should probably be returning a 303 for POSTs and not a 302.)
I'd reached the same conclusion this evening.
>I'm not sure why you believe the GET is unreliable, but an additional
>option is to communicate the parameters to be reused as the value of a cookie.
Two reasons:-
1. The AOLServer documentation says:-
The "GET" method causes the field names and values to be passed to the
program in the QUERY_STRING environment variable.
The "POST" method causes the field names and values to be passed to the
program through standard input. If the input from your form may be long, it
is best to use the POST method because long strings can be truncated when
they are assigned to an environment variable.
(../admin/cgi-ch3.htm#8716) And who am I to doubt the wisdom ;-)
2. The textarea on a form can be large and I have had experience of error
414 ('URI too long' I think?) in JSP (not my project).
Don't want to use cookies as I can't guarantee support. This site will
eventually support handheld devices running Opera 5 for EPOC and I'm trying
to keep it all on the server side for compatibility.
>And, frankly, thanks for labeling the crass option as crass. That's what
>the ACS does, and I've written in several times at several stages of
>development to try and convince them to change the behavior to be a "go
>forward" and not "go back" behavior. No Joy.
So how do people do it? Anyone?
Steve
