[Webkit-unassigned] [Bug 139097] New: Problem in modify a request of a redirected page in resource-request-starting signal

[bugzilla-daemon at webkit.org]

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

            Bug ID: 139097
           Summary: Problem in modify a request of a redirected page in
                    resource-request-starting signal
    Classification: Unclassified
           Product: WebKit
           Version: 420+
          Hardware: Unspecified
                OS: Other
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: semarie-openbsd at latrappe.fr

Hi,

According to the documentation, the resource-request-starting signal is the place where modification of request may occurs.

This works great, but in the case of a redirection, the modification don't come back to web_view (or any other compoment) whereas the request is done at good place.

I wrote a minimal test-case at https://github.com/semarie/webkit-change-uri
The test-case exhibe two differents comportements (faulty one, and good one):

The odd one (request modification after redirection):
 - webkit_web_view_load_uri http://bit.ly/1sXuZsu (it is a redirection to http://projects.dm.id.lv/s/hsts-testresult.html)
 - in resource-request-starting callback,
     rewrite http://projects.dm.id.lv/s/hsts-testresult.html request to https://projects.dm.id.lv/s/hsts-testresult.html
     (so, after redirection occurs)

The page displayed is https://projects.dm.id.lv/s/hsts-testresult.html
The uri (webkit_web_view_get_uri) is http://projects.dm.id.lv/s/hsts-testresult.html

Please note the http in uri whereas the page displayed is the https one.

Full trace:
$ ./change-uri http://bit.ly/1sXuZsu
notify::load-status: WEBKIT_LOAD_PROVISIONAL: (null)
resource-request-starting: uri=http://bit.ly/1sXuZsu
resource-request-starting: uri=http://projects.dm.id.lv/s/hsts-testresult.html
resource-request-starting: switch projects.dm.id.lv from HTTP to HTTPS
notify::load-status: WEBKIT_LOAD_COMMITTED: http://projects.dm.id.lv/s/hsts-testresult.html
resource-request-starting: uri=http://projects.dm.id.lv/favicon.ico
resource-request-starting: switch projects.dm.id.lv from HTTP to HTTPS
notify::load-status: WEBKIT_LOAD_FIRST_VISUALLY_NON_EMPTY_LAYOUT: http://projects.dm.id.lv/s/hsts-testresult.html
notify::load-status: WEBKIT_LOAD_FINISHED: http://projects.dm.id.lv/s/hsts-testresult.html
resource-request-starting: uri=https://projects.dm.id.lv/Favicon.ico


A Usual (and good) one (classical request modification):
 - webkit_web_view_load_uri http://projects.dm.id.lv/s/hsts-testresult.html
 - in resource-request-starting callback,
     rewrite http://projects.dm.id.lv/s/hsts-testresult.html request to https://projects.dm.id.lv/s/hsts-testresult.html

The page displayed is https://projects.dm.id.lv/s/hsts-testresult.html
The uri (webkit_web_view_get_uri) is https://projects.dm.id.lv/s/hsts-testresult.html

Full trace:
$ ./change-uri http://projects.dm.id.lv/s/hsts-testresult.html
notify::load-status: WEBKIT_LOAD_PROVISIONAL: (null)
resource-request-starting: uri=http://projects.dm.id.lv/s/hsts-testresult.html
resource-request-starting: switch projects.dm.id.lv from HTTP to HTTPS
notify::load-status: WEBKIT_LOAD_COMMITTED: https://projects.dm.id.lv/s/hsts-testresult.html
resource-request-starting: uri=https://projects.dm.id.lv/favicon.ico
notify::load-status: WEBKIT_LOAD_FIRST_VISUALLY_NON_EMPTY_LAYOUT: https://projects.dm.id.lv/s/hsts-testresult.html
notify::load-status: WEBKIT_LOAD_FINISHED: https://projects.dm.id.lv/s/hsts-testresult.html
resource-request-starting: uri=https://projects.dm.id.lv/Favicon.ico

Thanks.

-- 
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/20141129/fbbe579e/attachment-0002.html>