[ic] area tag broken for full URLs

Gert van der Spoel gert at 3edge.com
Thu Feb 9 21:09:48 UTC 2017

> -----Original Message-----
> From: interchange-users-bounces at icdevgroup.org [mailto:interchange-users-
> bounces at icdevgroup.org] On Behalf Of Peter
> Sent: Thursday, February 9, 2017 22:46
> To: interchange-users at icdevgroup.org
> Subject: Re: [ic] area tag broken for full URLs
> On 09/02/17 21:22, Gert van der Spoel wrote:
> > I think that this is intended behavior. When you look at:
> > http://interchange.rtfm.info/icdocs/tags/area.html
> Right, I think this is the case of a long-standing bug having been
> > So if you take the approach of: You should only use the area tag for
> > Interchange URLs then the code works as is.
> ...which is likely why this hasn't turned up before, because hardly anyone
> it that way.
> If you have a look at the code for tag_area() in Interpolate.pm, look at
> 2728-2752.  That entire block is created to deal with fully qualified URLS
> the vast majority of it is created to deal with those in combination with
> form attribute.  It is apparent that it is fully intended to work this way
or that
> code would not be there at all.  Note that the block strips the domain
> of the URL and places it in $r (which is initialized on line 2723,
> outside of the block so it can be used later in the function).  Also note
that in
> no place is the content of $r actually used, so a lot of effort has been
taken to
> store content in $r but then it is simply abandoned.  This is suggestive
of a
> feature that was intended but wasn't created properly.
> In addition, if you look at the call to vendUrl() at line 2767, note the
3rd arg is
> undef there.  But look at the actual assignment of args to vendUrl in
> line 1321, it shows that the third arg gets assigned to $r there.  It's
> coincidence that $r is the same variable name as the $r in tag_area() that
> never used, it's clearly supposed to be assigned there (and in my testing
when I
> do change the undef to $r the code works as it appears it is intended).
> Only Mike knows for sure what he intended when he wrote the code, but I
> think the evidence points clearly to that it was intended to work this way
> the fact that it doesn't is a bug that is easily fixed.
> > And if you'd make the fix as you suggested there will be some other
> > issues that will be confusing:
> >
> > When you have
> > $opt->{secure}  = 1  ...
> This is dealt with in line 2750, when a full URL is passed $opt->{secure}
> overridden to 0, but if the full URL is an https URL it will still be
secure because
> the https will be passed as part of $r.

Good point I overlooked that one. :)

> > Anyway I think it's better to not touch. :)
> I'm gonna disagree here.  I've done my homework (as you can see above) and
> changing that third arg to $r will not affect any usage where the href is
not a
> full URL since $r will be undef in that case anyways and hence be the same
> explicitly passing undef as is done now.
> The only reason I'm asking is because the current behavior is if you pass
a full
> URL with a form attribute, then the protocol://domain portion will be
> out and replaced by VendUrl.  I highly doubt anyone is relying on this
> behaviour, but if you are then speak up now because you're relying on a
> and it should be changed.

More information about the interchange-users mailing list