Re: Address Bar URI

The address bar situation is discussed here
http://www.w3.org/QA/2010/04/why_does_the_address_bar_show.html  with
reference to the Mozilla bug report.

Basically the browser folks think retaining the pre-forwarding URI
would be a kind of a lie, given that the content that's displayed came
from someplace other than the URI that's shown in the address bar.
There is a perceived security risk in certain situations since some
users look at the URI in order to decide whether to 'trust' content
while some servers don't 'stand by' pages they forward to. Since other
interventions (fixing servers and retraining users) won't work, the
fix would have to be some new UI element that showed *both* URIs.

Note that this is an issue for 302 and 307, not just 303.

It just occurred to me that now that the theory of origins (SOP, CORS,
history.replaceState(), etc.) is developed better than it was when
this issue was first raised, maybe the browser folks would be willing
to preserve the original URI in a redirect in the case where the
origin is unchanged. That constraint ought to placate the security
concerns, since with an unchanged origin the URI can be switched back
by Javascript - i.e. switching the URI bar from original to redirected
URI gives no protection.

(By the way please please stop using this 'NIR' acronym. Regardless of
what you think of 303, it's important to understand that it has
nothing whatsoever to do with a type distinction - it's about whether
the URI refers to the document found at the URI, vs. to something
else. The "something else" might itself be an "IR", as you can see at
dx.doi.org. So 303 definitely does not imply 'NIR'.)

Jonathan

On Fri, Oct 14, 2011 at 11:11 AM, David Wood <david@3roundstones.com> wrote:
> Hi Hugh,
>
> I like what you are saying and agree that this approach would be a real boon to the LOD community.  Practical problems with using it are likely to be with subtleties of browser implementation.
>
> For example, Firefox resets all headers on redirect, including the Accept: header which causes us difficulty with PURL redirects.  This is a known issue in Firefox and has been unfixed for four years:
>  https://bugzilla.mozilla.org/show_bug.cgi?id=401564
> The test page can be found here:
>  http://tc.labs.opera.com/apis/XMLHttpRequest/send-redirect.htm
>
> I recall a similar bug report on Firefox where Mozilla developers were discussing how the address bar contents should be modified, and there was violent disagreement.  Unfortunately, I can't put my hands on that URL at the moment, but I think you get my point: Each browser vendor will decide to handle these things differently in the absence of a standard (or in the presence of cross-site abuse concerns).
>
> The best way to proceed is probably to try it and test all major browsers.
>
> Regards,
> Dave
>
>
>
>
> On Oct 14, 2011, at 10:22, Hugh Glaser wrote:
>
>> Excellent, hopefully that is out of the way.
>> Does anyone want to express an opinion on the original question, which boils down to:
>>
>> "Is there a problem if going to URI http://www.myexperiment.org/workflows/158 (say, by clicking) in a browser then shows http://www.myexperiment.org/workflows/158 in the address bar for the page it displays?"
>>
>> I suggest not.
>>
>> It does bring one further question (at least):
>> What do you display if someone goes to http://www.myexperiment.org/workflows/158.html?
>> Possibly more controversial, as I suspect that the pragmatic answer is to display
>> http://www.myexperiment.org/workflows/158
>>
>> Best
>> Hugh
>>
>>
>> On 14 Oct 2011, at 14:23, Ian Davis wrote:
>>
>>> On Fri, Oct 14, 2011 at 2:15 PM, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>>
>>>
>>> Yes, opaque technology to you. Luckily, not for the rest of the computing universe.
>>>
>>> The large number of off-list messages supporting my view seems to provide evidence to the contrary.
>>>
>>> Apologies to the list for this off-topic conversation. I won't prolong it.
>>>
>>> Ian
>>
>> --
>> Hugh Glaser,
>>              Web and Internet Science
>>              Electronics and Computer Science,
>>              University of Southampton,
>>              Southampton SO17 1BJ
>> Work: +44 23 8059 3670, Fax: +44 23 8059 3045
>> Mobile: +44 75 9533 4155 , Home: +44 23 8061 5652
>> http://www.ecs.soton.ac.uk/~hg/
>>
>>
>>
>
>
>

Received on Friday, 14 October 2011 20:11:42 UTC