[Webkit-unassigned] [Bug 136938] XMLHttpRequest should have a responseURL attribute (added in recent XHR specification drafts)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=136938

--- Comment #37 from Shivakumar J M <shiva.jm at samsung.com> ---
(In reply to comment #35)
> Comment on attachment 240115 [details]
> Patch-Updated-Review6
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=240115&action=review
> 
> http/tests/xmlhttprequest/xmlhttprequest-responseURL.html fails on EWS.
> 
> > Source/WebCore/platform/network/ResourceResponseBase.cpp:153
> > +    m_url.removeFragmentIdentifier();
> 
> By doing it at this level, you are effectively saying that response URL can
> never have a fragment identifier. How did you determine that this is
> correct? This change goes way beyond the purpose of this patch.
> 
> I do not have any easy way to determine whether this change is OK. It looks
> like it may not break anything at the moment, but only because of bugs in
> other places, and fragment actually needs to be respected - see bug 24175.
> 
> > Source/WebCore/xml/XMLHttpRequest.cpp:340
> > +    return m_response.url().string();
> 
> The right place to remove fragment is in this accessor.

Dear Alexey,

Thanks for inputs, actually i had doubt in mind whether to filter fragments in XMLHttpRequest.cpp or in ResourceResponseBase.cpp, since ResourceResponseBase::url() was returning const URL object, i felt instead of filtering the fragments in upper XMLHttpRequest class, lets filter in core side and set the filtered URL, so that it will be done once. 
I think sa per bug 24175 and spec, it should be done in XMLHttpRequest class.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20141021/dd73def7/attachment-0002.html>