[ic] area tag broken for full URLs

Peter peter at pajamian.dhs.org
Thu Feb 9 20:46:05 UTC 2017

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 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.

> 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.


More information about the interchange-users mailing list