Am Montag, 15. September 2003 13:00 schrieb Paul L. Allen:Wolfgang Ebneter writes:Hm, sorry should have put it correctly as http status code.When I try to access it from the internet the webserver's log shows an
303 error.
303 is not an error, it is a redirect and exist primarily to allow the output from a POST request to redirect the browser elsewhere.
[...]I have no problem to connect directly to the server.I suggest you check out what happens if you go direct to the server instead of through the proxy.
Hmm... Sorry, but I sent a reply to this the other day before leaving town, but from the wrong address... So it didn't make it through the list server.
Let me try again. :)
You already got a similar comment about 303 not being an error code, but merely a redirect code. Nonetheless, the rest of my previous (but undelivered) message -- which I've included below -- might be helpful to you. At least I hope it will be.
-jab
----- From: James A Baker < [EMAIL PROTECTED] > Date: Sun Sep 14, 2003 10:21:25 US/Central To: [EMAIL PROTECTED] Subject: Re: [sqwebmail] Problems accessing sqwebmail
On Sunday, Sep 14, 2003, at 05:45 US/Central, Wolfgang Ebneter wrote:
Hi all,
I compiled and installed sqwebmail just fine. I can acces sqwebmail in
apache's cgi-bin directory from the intranet.
When I try to access it from the internet the webserver's log shows an 303
error.
All access attempts to the machine where sqwebmail runs goes first to a proxy
which contacts the internal server, gets the answer and delivers it to the
user.
The sqwebmail binary runs as root with the access-rights set to rwsr-xr-x.
The webserver runs as user www and group www.
Is there a wail to enable sqwebmail to write to some logfile to see what
happens ?
thanks Wolfy
Hi Wolfy. Just so you know... 303 is not an error. It is a response code indicating a redirect.
However, your proxy is probably not HTTP 1.1 compliant. Old HTTP 1.0 (or 0.9) proxies typically do not understand the 303 response. I couldn't say what trouble exactly is occurring when your proxy gets the 303 response (or when it tries to pass it along), but that's most likely where the problem is.
Perhaps the proxy is returning the full redirect location without altering the server name to use. I.e. it's sending back your internal server name, which the outside client can't reach. Or maybe it just doesn't understand the 303 response at all, and is flaking out. I couldn't really say.
Of course, it could be a client issue I suppose, but that seems unlikely since you can access it from the intranet, which presumably doesn't go through the proxy. So, I really suspect the proxy is indeed your problem.
See RFC 2616 (HTTP/1.1), specifically section 10.3.4's note:
10.3.4 303 See Other
The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.
The different 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).
Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.
Solutions:
A) Upgrade your proxy to a version (or another proxy product--ouch!) that does understand HTTP 1.1 fully, so that the 303 will be handled properly.
B) Hack SqWebMail's code locally, so that instead of 303, it returns 302.
HTH... And good luck with whichever one you choose! :)
-jab -----
