[whatwg] HTML5 History Management

Sorry, same domain policy is clearly defined. I just missed it.

> Compare the resulting absolute URL to the document's address. If any part
> of these two URLs differ other than the <path>, <query>, and <fragment>
> components, then raise a SECURITY_ERR exception and abort the pushState()
> steps.



On Thu, Jul 30, 2009 at 4:27 PM, Sebastian Markb?ge
<sebastian at calyptus.eu>wrote:

> Jonas,
>
> That is my interpretation too. But I think it's a little unclear whether
> that means that the UA should update any Location fields in the UI. I
> understand that this may be optional or outside the scope, but I think that
> it should still be mentioned.
>
> Now if the UA is suppose to update the Location field, shouldn't push state
> URL be subject to same-domain policies? Is that defined clearly?
>
> Otherwise, this can be used during phishing attacks.
>
> Sebastian
>
> On Thu, Jul 30, 2009 at 4:13 PM, Nathan Hammond <nathan at nathanhammond.com>wrote:
>
>> Hey Jonas et al.:
>> Thanks for the reply, forgive my disbelief on Clarification 1. :) If I'm
>> completely with you, that is entirely unexpected on my part (and I've read
>> this part of the spec a few times). Is this to imply that, no matter what
>> the arguments to pushState(), if the path is relative to the current URL
>> there will be no request for a new document and no user-agent initiated
>> network activity?
>>
>> This is a behavior I'm fine with and will meet my needs just as well, I
>> was simply expecting to have to use the approach from Clarification 2 in
>> order to retain my document object. It does however lend itself to some
>> confusion when paired with user agents that don't yet support the history
>> portions of the spec as they will have to be handled with hash-based
>> addressing while those that support pushState() will have more sane
>> URLs--but that is no matter in the grand scheme of things.
>>
>> Also, that would imply that the popstate only fires when you're navigating
>> through history. Is that correct?
>>
>> Thanks!
>> Nathan
>>
>>
>> On Jul 30, 2009, at 4:42 AM, Jonas Sicking wrote:
>>
>>  On Wed, Jul 29, 2009 at 7:38 PM, Nathan Hammond<nathan at nathanhammond.com>
>>> wrote:
>>>
>>>> Clarifications
>>>> 1. window.history.pushState({}, "Title",
>>>> "/path/to/new/file.html?s=newvalue#newhash") replaces the current
>>>> document
>>>> object with the one specified by the new URL. It then causes the event
>>>> popstate to fire immediately after the load event, correct?
>>>>
>>>
>>> No. The above line with change the uri of the existing document to be
>>> "http://example.com/path/to/new/file.html?s=newvalue#newhash" (with
>>> the part before 'path' obviously depending on where the original page
>>> lives).
>>>
>>> So no network activity takes place and the Document node remains the
>>> same. Also no popstate event is fired.
>>>
>>>  2. window.history.pushState({}, "Title", "#newhash") creates a new
>>>> history
>>>> state object with the specified data object, the specified title, the
>>>> same
>>>> document object, and a location object that replaces the existing hash
>>>> with
>>>> "#newhash", correct?
>>>>
>>>
>>> Yes.
>>>
>>> / Jonas
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090730/9074f209/attachment-0001.htm>

Received on Thursday, 30 July 2009 07:40:41 UTC