Miernik <[EMAIL PROTECTED]> writes: > In my Alias section I have: > > http://www.linuxbios.org/* = http://linuxbios.org/* > > When I go to http://linuxbios.org/mailman/options/linuxbios > and I fill in the Email address: and Password: the form is posted by the > browser to the URL with www: > > <FORM action="http://www.linuxbios.org/mailman/options/linuxbios"; > method="POST" > > > WWWOFFLE redirects that to > http://linuxbios.org/mailman/options/linuxbios which is what I wanted, > but without the POST value, it just makes a GET query to that address, > which is not what should be done in such case, why doesn't it POST my > data to http://linuxbios.org/mailman/options/linuxbios ? > Is that a bug, or is this intentional?
There may be a bug, but it isn't as obvious as it may seem. What happens with an Alias option in the configuration file when you are online is that WWWOFFLE sends the browser a response code 302 "redirect" message with the new URL specified. When you make the request offline then the aliasing will occur at that time so that the request that WWWOFFLE stores is for a URL which isn't aliased. If you make a request when offline for a URL that has no alias and then change the configuration file so that the URL does have an alias then when fetching the page online I am not sure what WWWOFFLE does. > Jun 2 21:15:55 tarnica wwwoffled[11468]: Forked wwwoffles -real (pid=14820). > Jun 2 21:15:55 tarnica wwwoffles[14820]: > URL='http://www.linuxbios.org/mailman/options/linuxbios?!POST:c41q0LTjwleIkc1AGsN9Qw.4661c1eb'. > Jun 2 21:15:55 tarnica wwwoffles[14820]: Aliased > URL='http://linuxbios.org/mailman/options/linuxbios'. > Jun 2 21:15:55 tarnica wwwoffled[11468]: Forked wwwoffles -real (pid=14821). > Jun 2 21:15:55 tarnica wwwoffles[14821]: > URL='http://linuxbios.org/mailman/options/linuxbios'. As you can see here the browser sends the first request, WWWOFFLE sends the redirection page (not visible in log) and then the browser requests the redirected page. The HTTP/1.0 specification is clear about what should happen here: -------------------- RFC1945 -------------------- 302 Moved Temporarily The requested resource resides temporarily under a different URL. Since the redirection may be altered on occasion, the client should continue to use the Request-URI for future requests. The URL must be given by the Location field in the response. Unless it was a HEAD request, the Entity-Body of the response should contain a short note with a hyperlink to the new URI(s). If the 302 status code is received in response to a request using the POST method, 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 302 status code, some existing user agents will erroneously change it into a GET request. -------------------- RFC1945 -------------------- The HTTP/1.1 specification is even more clear that a 302 message should be redirected by the browser for another POST request. -------------------- RFC2616 -------------------- 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. -------------------- RFC2616 -------------------- There may be some good reason that POST requests are not redirected by browsers, perhaps some security reason. The reason that WWWOFFLE must redirect the browser rather than just use the aliased URL directly is to avoid the browser becoming confused. If WWWOFFLE loaded a different page than the one that the browser requested then any relative links could point to places that are not aliased. If "http://www.bar/"; is aliased to "http://www.foo/bar/"; then a request for the URL "http://www.bar/aaa.html"; will tell the browser to switch to the URL "http://www.foo/bar/aaa.html";. A link from this page to "../bbb.html" will be interpreted by the browser as being "http://www.foo/bbb.html"; which is correct. If WWWOFFLE did the redirection then the browser would think that the first page was still "http://www.bar/aaa.html"; so that the link to "../bbb.html" would not make sense and would probably lead the browser to requesst "http://www.bar/bbb.html";. WWWOFFLE would interpret this as another alias request and serve the contents of "http://www.foo/bar/bbb.html"; when it isn't what the browser is telling the user and is the wrong URL. -- Andrew. ---------------------------------------------------------------------- Andrew M. Bishop [EMAIL PROTECTED] http://www.gedanken.demon.co.uk/ WWWOFFLE users page: http://www.gedanken.demon.co.uk/wwwoffle/version-2.9/user.html
