Re: area tag broken for full URLs

> -----Original Message-----
> From: [email protected] [mailto:interchange-users-
> [email protected]] On Behalf Of Peter
> Sent: Thursday, February 9, 2017 22:46
> To: [email protected]
> 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
documented.
> 
> > 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
uses
> it that way.
> 
> If you have a look at the code for tag_area() in Interpolate.pm, look at
lines
> 2728-2752.  That entire block is created to deal with fully qualified URLS
and
> the vast majority of it is created to deal with those in combination with
the
> 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
portion
> of the URL and places it in $r (which is initialized on line 2723,
purposefully
> 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
Util.pm
> line 1321, it shows that the third arg gets assigned to $r there.  It's
not
> coincidence that $r is the same variable name as the $r in tag_area() that
is
> 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
and
> 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}
is
> 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
as
> 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
stripped
> 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
bug
> and it should be changed.
> 
>