Miernik <[EMAIL PROTECTED]> writes:
> If an URL is matched in the [Alias] section, and it happens that you
> want to do a POST to an URL like that, it is impossible.
>
> Here is what happens. This is a transcript of headers of HTTP requests
> and reply's with irrelevant headers removed for clarity. Content of the
> POST is also ommited, its irrelevant.
>
> This was after visiting the URL
> http://kwiki.ffii.org/index.cgi?action=edit&page_id=SandBoxEn
> while having
> http://wiki.ffii.org/* = http://kwiki.ffii.org
> in the [Alias] section, and typing some characters in the textarea there
> and pressing SAVE.
>
>
> POST http://wiki.ffii.org/index.cgi HTTP/1.1
> Host: wiki.ffii.org
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 273
>
>
> HTTP/1.1 302 WWWOFFLE Alias Redirect
> Server: WWWOFFLE/2.8e
> Location:
> http://kwiki.ffii.org/index.cgi?!POST:wVBa96MgM1w8CfKyHnmcbw.4241aad1
> Content-type: text/html
>
>
> GET http://kwiki.ffii.org/index.cgi?!POST:wVBa96MgM1w8CfKyHnmcbw.4241aad1
> HTTP/1.1
> Host: kwiki.ffii.org
>
>
> HTTP/1.1 404 WWWOFFLE Cant Refresh POST/PUT
> Server: WWWOFFLE/2.8e
> Content-type: text/html
>
>
>
> Do any POSTs work for anyone while the address to POST to is matched by
> a rule in [Alias] section?
I can see two bugs here.
The first one is that WWWOFFLE is redirecting you to a URL that
contains '?!POST:wVBa96MgM1w8CfKyHnmcbw.4241aad1' which is an internal
reference and not a valid external URL.
The second one is that the browser is making a GET request the second
time which means that even if the WWWOFFLE bug above was fixed it
still wouldn't work.
The HTTP specification makes reference to the second of these (for a
slightly different case)
-------------------- RFC 2616 --------------------
If the 301 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: When automatically redirecting a POST request after
receiving a 301 status code, some existing HTTP/1.0 user agents
will erroneously change it into a GET request.
-------------------- RFC 2616 --------------------
For a type 302 code which is what WWWOFFLE sends the relevant text is
changed to:
-------------------- RFC 2616 --------------------
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.
-------------------- RFC 2616 --------------------
The type 303 status code says to use a GET request and the type 307
code has this text:
-------------------- RFC 2616 --------------------
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.
-------------------- RFC 2616 --------------------
Both 303 and 307 are not likely to be understood by a non-HTTP/1.1
client.
In any case it is not clear what error code WWWOFFLE should be using
since obviously a 302 code does not work for you (and wouldn't anyway
because of the WWWOFFLE bug).
--
Andrew.
----------------------------------------------------------------------
Andrew M. Bishop [EMAIL PROTECTED]
http://www.gedanken.demon.co.uk/
WWWOFFLE users page:
http://www.gedanken.demon.co.uk/wwwoffle/version-2.8/user.html
