>The problem here is that the ns_returnredirect tries to use a GET method to
>return the value of the notes textarea which isn't very reliable. I would
>like to replace the ns_returnredirect in the tcl proc with a post to the
>adp page. If anyone has a different approach to this problem I would
>appreciate the input.
>
>The crass options are to display the error with a message telling the user
>to hit the Back button or to show the form page with the error but present
>a new blank form. Another option is to store the values on the server
>somewhere and have the adp page retreive them (abit like a jsp session).
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.)
>10.3.3 302 Found
>The requested resource resides temporarily under a different URI. Since
>the redirection might be altered on occasion, the client SHOULD continue
>to use the Request-URI for future requests. This response is only
>cacheable if indicated by a Cache-Control or Expires header field.
>
>The temporary URI SHOULD be given by the Location field in the response.
>Unless the request method was HEAD, the entity of the response SHOULD
>contain a short hypertext note with a hyperlink to the new URI(s).
>
>If the 302 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.
>
> Note: RFC 1945 and RFC 2068 specify that the client is not allowed
> to change the method on the redirected request. However, most
> existing user agent implementations treat 302 as if it were a 303
> response, performing a GET on the Location field-value regardless
> of the original request method. The status codes 303 and 307 have
> been added for servers that wish to make unambiguously clear which
> kind of reaction is expected of the client.
Anyway, it is expressed in terms of URIs, and URIs include the query but
not the post, you can expect the user agents, i.e., IE, (yes, that was fun
thank you) to ignore any posted information back to
them. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2
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.
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.
Yours,
Jerry
=====================================================
Jerry Asher [EMAIL PROTECTED]
1678 Shattuck Avenue Suite 161 Tel: (510) 549-2980
Berkeley, CA 94709 Fax: (877) 311-8688
