Robert,
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.
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?
Charles Daminato
TUCOWS Product Manager (ccTLDs)
[EMAIL PROTECTED]
On Tue, 30 Jan 2001, Tiger Technologies wrote:
> At 1/30/01 3:25 PM, Charles Daminato wrote:
>
> >My apologies - I meant the page prior to the "Wrong type" page. I want to
> >see what the Mac browser is interpreting, and then sending to our system.
>
> Well, it's exactly the same source on Netscape and MSIE, so that isn't it.
>
> However, I've experimented and found the problem. The URL sent to the
> OpenSRS servers is (for example):
>
> http://rr-n1-tor.opensrs.net/redirect?type=tv_highprice&reseller=tigertech&
> domain=monkeys.tv
>
> When you first do that, the OpenSRS server returns a redirect to:
>
> http://rr-n1-tor.opensrs.net/redirect/?type=tv_highprice&reseller=tigertech
> &domain=monkeys.tv
>
> Note the extra slash after "redirect". The cause of this is that the URL
> in the OpenSRS.conf file is incorrect. I mention this in passing, because
> it's actually not causing the problem I set out to diagnose, but it
> should be fixed because it's forcing an extra redirect.
>
> The real problem is that when a query for the second URL (with the slash)
> occurs, the server responds with (among other headers):
>
>
> HTTP/1.1 302 Found
> Date: Wed, 31 Jan 2001 00:33:25 GMT
> Server: Apache/1.3.12 (Unix) mod_ssl/2.6.5 OpenSSL/0.9.5a mod_perl/1.24
> Content-Location: index.cgi
> Location:
> http://www.tv/cgi-bin/lookup.cgi?domain=monkeys.tv&tld=tv&refererid=Tucows-
> 61
>
>
> The "Content-Location" field, while apparently legal, is confusing the
> browser. It is using "Content-Location" instead of "Location" (buggy
> Microsoft cr*p; I suspect they're just looking for a header containing
> "Location: " and using that).
>
> I believe that if Content-Location were removed from the server response
> (it's unnecessary for redirects), the problem would go away.
>
> --
> Robert L Mathews, Tiger Technologies
>
>