Mailing List Archive

imap fix...
I was running into a bug where the Location: returned for some imagemap
accesses was not a complete URL, but a relative one - Netscape handled it
fine (aarg! in violation of the spec) but other conforming browsers didn't
like it (funny watching XMosaic try and FTP to "." :) Turns out this was just
for "default" entries - Randy (and other imagemap gurus) - what do you think
of this fix?


*** mod_imap.c.old Fri Sep 8 12:20:57 1995
--- mod_imap.c Wed Oct 4 00:37:43 1995
***************
*** 424,430 ****

if (mapdflt[0]) {

! table_set (r->headers_out, "Location", mapdflt);
fclose(imap);
return REDIRECT;
}
--- 424,430 ----

if (mapdflt[0]) {

! set_redirect (r, base_uri, mapdflt);
fclose(imap);
return REDIRECT;
}



Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: imap fix... [ In reply to ]
>
> I was running into a bug where the Location: returned for some imagemap
> accesses was not a complete URL, but a relative one - Netscape handled it
> fine (aarg! in violation of the spec) but other conforming browsers didn't
> like it (funny watching XMosaic try and FTP to "." :) Turns out this was just
> for "default" entries - Randy (and other imagemap gurus) - what do you think
> of this fix?


I see a problem if 'base_uri' is not set. The 'base_uri' field was
considered optional. It looks like you would only be having a problem
IF 'default' is a relative URL? Also, if you are trying to do 'ftp'
from the map, it's not properly supported. This was brought to my
attention recently. I thought I would add it along with some of the
new features in the imagemap.c that Tony Sanders pointed to, as well
as take a look at the polygon code that was recently sent to the list
*after* 1.0 is released.



> *** mod_imap.c.old Fri Sep 8 12:20:57 1995
> --- mod_imap.c Wed Oct 4 00:37:43 1995
> ***************
> *** 424,430 ****
>
> if (mapdflt[0]) {
>
> ! table_set (r->headers_out, "Location", mapdflt);
> fclose(imap);
> return REDIRECT;
> }
> --- 424,430 ----
>
> if (mapdflt[0]) {
>
> ! set_redirect (r, base_uri, mapdflt);
> fclose(imap);
> return REDIRECT;
> }
>
>
>
> Brian
>
>
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: imap fix... [ In reply to ]
On Wed, 4 Oct 1995, Randy Terbush wrote:
> > I was running into a bug where the Location: returned for some imagemap
> > accesses was not a complete URL, but a relative one - Netscape handled it
> > fine (aarg! in violation of the spec) but other conforming browsers didn't
> > like it (funny watching XMosaic try and FTP to "." :) Turns out this was just
> > for "default" entries - Randy (and other imagemap gurus) - what do you think
> > of this fix?
>
>
> I see a problem if 'base_uri' is not set.

Yup, base_uri was not set. Want to keep these portable to other
imap-supporting servers...

> The 'base_uri' field was
> considered optional. It looks like you would only be having a problem
> IF 'default' is a relative URL?

Yes, I should have made that clear.

> Also, if you are trying to do 'ftp'
> from the map, it's not properly supported.

Nope, my comment about XMosaic trying to FTP to "." was that that was
how XMosaic decided to respond to the header

Location: /some/file

instead of

Location: http://host/some/file

> This was brought to my
> attention recently. I thought I would add it along with some of the
> new features in the imagemap.c that Tony Sanders pointed to, as well
> as take a look at the polygon code that was recently sent to the list
> *after* 1.0 is released.

My fix feels like a bug fix though... if we're doing one more build
before 1.0 it should make it in. Should I submit the patch formally?

Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/
Re: imap fix... [ In reply to ]
> My fix feels like a bug fix though... if we're doing one more build
> before 1.0 it should make it in. Should I submit the patch formally?
>
> Brian
>

This fix looks fine to me. It essentially is just running the 'default'
through the URL munger which it should have in the first place. Good
catch.