At 1/30/01 5:46 PM, Charles Daminato wrote:
>Fantastic! I'll see if this can be altered tomorrow. As for the slash in
>the OpenSRS.conf file - I'm not sure if it should be removed. Either way
>works properly, WITH the slash I get the "Content-Location" in the HTTP
>headers.
Sorry, I don't think I made myself quite clear -- the URL without the
slash is the one that's in the OpenSRS.conf file as it ships. When the
client uses that URL, the OpenSRS server immediately redirects it to the
one with the slash before it even gets to the other problematic redirect.
It doesn't hurt anything, but wastes some time and server connections. To
avoid that needless redirect, there does need to be a slash after
"redirect" (because the client is trying to go to a directory named
"redirect" on your server, and directories have to end with a slash).
In any case, it has no bearing on the other problem. I was just pointing
it out because I happened to see it while examining the headers.
>If I add index.cgi (i.e. .....net/redirect/index.cgi?type=...) the
>"Content-Location" header is gone, and everything works as you'd expect.
>Can you try this out for me in your OpenSRS.conf?
It does remove the bad header in testing with netcat and telnet, but it
causes a new problem in both Netscape and MSIE if you try replacing it in
OpenSRS.conf and testing with a browser. The server never responds with
the redirect (or anything else); I assume this is something to do with
the slightly odd mixture of the POST request and the parameters passed as
a query string.
I don't know why this problem doesn't happen when you omit the
"index.cgi", but anyway, adding it makes things worse. (I'd be interested
in hearing why if you figure it out; Apache index file CGIs should behave
the same way as if you explicitly specify the CGI as far as I know. Maybe
you have a rewrite rule that's doing some other magic.)
Sorry :-( It looks like you'll have to try to eliminate the extra
header some other way.
--
Robert L Mathews, Tiger Technologies
