Summary: | [soup] URL of the ResourceResponse passed to willSendRequest is incorrect | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Chris Dumez <cdumez> | ||||||||||||||
Component: | WebCore Misc. | Assignee: | Chris Dumez <cdumez> | ||||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||||
Severity: | Normal | CC: | danw, d-r, gustavo, mrobinson, rakuco, svillar, webkit.review.bot | ||||||||||||||
Priority: | P2 | ||||||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||||||
Hardware: | Unspecified | ||||||||||||||||
OS: | Unspecified | ||||||||||||||||
Bug Depends on: | 82704, 85173 | ||||||||||||||||
Bug Blocks: | |||||||||||||||||
Attachments: |
|
Description
Chris Dumez
2012-04-27 09:12:55 PDT
Created attachment 139218 [details]
Proposed patch
Comment on attachment 139218 [details]
Proposed patch
This looks reasonable to me, but I'm unfamiliar with what the correct behavior is. Does this affect tests? The patch should probably include new results so we can confirm that this is progression.
FYI, only those 3 tests expect redirect responses in willSendRequest: - http/tests/misc/will-send-request-returns-null-on-redirect.html - http/tests/loading/redirect-methods.html - http/tests/loading/307-after-303-after-post.html All 3 of them are currently skipped in both GTK and EFL ports. (In reply to comment #3) > FYI, only those 3 tests expect redirect responses in willSendRequest: > > - http/tests/misc/will-send-request-returns-null-on-redirect.html > - http/tests/loading/redirect-methods.html > - http/tests/loading/307-after-303-after-post.html > > All 3 of them are currently skipped in both GTK and EFL ports. Perhaps we can unskip them after this change? That would be awesome. Unfortunately, those tests cannot be unskipped at this point because they are missing other functionality. I will implement those missing functionality in separate patches so that the tests can be unskipped in this bug report. The GTK+ port's DRT has a bit more functionality than than the EFL port's. What's still missing for GTK+? This patch looks okay to me, but you should probably make a note in the ChangeLog that this will fix these three tests in the future. I'd also like to get an informal review from some people more familiar with the soup backend. I added the other bugs (for EFL port) as dependency and I will wait for those to land before rebasing this path and unskipping the 3 test cases for EFL port. The GTK port is also missing similar functionality to unskip the tests (at least willSendRequestReturnsNullOnRedirect) but I'm less familiar with the code. I can take a look at it afterwards though. With this patch, it appears the following tests can be unskipped in GTK port: - http/tests/loading/redirect-methods.html - http/tests/loading/307-after-303-after-post.html The following test does not pass yet because of missing support for willSendRequestReturnsNullOnRedirect(). I'll look into it. (In reply to comment #8) > With this patch, it appears the following tests can be unskipped in GTK port: > - http/tests/loading/redirect-methods.html > - http/tests/loading/307-after-303-after-post.html > > The following test does not pass yet because of missing support for willSendRequestReturnsNullOnRedirect(). I'll look into it. Please disregard this last comment, none of the tests are passing on GTK port (test_expectations.txt fooled me). Based on the output, it seems it is due to the following features missing: - willSendRequestReturnsNullOnRedirect() - Missing "willPerformClientRedirectToURL" messages (part of dumpFrameLoadCallbacks) - Missing "didReceiveServerRedirectForProvisionalLoadForFrame" messages (part of dumpFrameLoadCallbacks) - Missing "didCancelClientRedirectForFrame" messages (part of dumpFrameLoadCallbacks) Comment on attachment 139218 [details]
Proposed patch
Hmm. I think you are right, but this is only a partial fix. The URL will be the old one, but all the headers will be the new ones, which is also not expected. I think we'll need to store the response we get earlier by reintroducing a got-headers signal handler, and then use it here.
Created attachment 139760 [details]
Patch
Proper fix proposal based on Gustavo Noronha's input.
Comment on attachment 139760 [details]
Patch
Clearing flags as the patch is wrong (Response storing code)
Created attachment 139766 [details]
Patch
Ok, here is the fixed patch.
2 things I would like to mention:
- The m_response is now probably updated twice (first in gotHeadersCallback() when we get the headers and then in sendRequestCallback())
- Would it make sense to move the WEB_TIMING receiveHeadersEnd update code from sendRequestCallback() to gotHeadersCallback() now that we listen for the "got-headers" signal?
(In reply to comment #13) > Created an attachment (id=139766) [details] > Patch > > Ok, here is the fixed patch. > > 2 things I would like to mention: > - The m_response is now probably updated twice (first in gotHeadersCallback() when we get the headers and then in sendRequestCallback()) Indeed, thing is that content sniffing has not happened by the time got-headers is emitted so we need to wait for sendRequestCallback in that case > - Would it make sense to move the WEB_TIMING receiveHeadersEnd update code from sendRequestCallback() to gotHeadersCallback() now that we listen for the "got-headers" signal? I think it'd make total sense In any case I think that this patch should include the unskipping of the 3 tests you mention. I think we should wait till you land the required DRT stuff to push this in. Anyway if Gustavo and Martin are ok with that, they're the reviewers :) Created attachment 139782 [details]
Patch
Move WEB_TIMING receiveHeadersEnd update code from sendRequestCallback() to new gotHeadersCallback() callback based on Sergio Villar Senin's feedback.
Comment on attachment 139782 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=139782&action=review I agree with Sergio it would be better to land this while unskipping the tests. I had a couple of nits, so I'll mark this r- so it gets out of the review queue, but the code looks good to me. > Source/WebCore/platform/network/soup/ResourceHandleSoup.cpp:218 > +// Called afer receiving all headers for the message. I don't think this comment adds value, I suggest removing it. However, it may be puzzling for someone reading the code to understand exactly why we handle got-headers and update d->m_response while doing it, so... > Source/WebCore/platform/network/soup/ResourceHandleSoup.cpp:236 > + ResourceResponse response; > + response.updateFromSoupMessage(msg); > + > + d->m_response = response; ... if you could add something to the effect of 'We need to have the original response to feed to willSendRequest in case we are redirected, so we store it here.' close to these lines, I think it would help our future readers =) Created attachment 139959 [details]
Patch
Update the patch to take Gustavo Noronha's feedback into consideration.
Note that I cannot unskip the 3 tests until the 2 bugs in dependency get closed (need formal review).
Comment on attachment 139959 [details]
Patch
OK, looks like we can now unskip those tests (thus cq-), rest of the patch looks good, though.
Created attachment 140283 [details] Patch Here is the updated patch which unskips: - http/tests/misc/will-send-request-returns-null-on-redirect.html - http/tests/loading/307-after-303-after-post.html To my surprise the following test was not passing on my machine anymore due to part of the output being missing: - http/tests/loading/redirect-methods.html After browsing the bug tracker, I found: Bug 66873 - http/tests/loading/redirect-methods.html occasionally missing chunks of output It seems there is another unrelated bug which causes http/tests/loading/redirect-methods.html to fail sometimes to I'm keeping it in test_expectations (and updating its bug number). Comment on attachment 140283 [details]
Patch
Good catch, thanks!
Comment on attachment 140283 [details] Patch Clearing flags on attachment: 140283 Committed r116160: <http://trac.webkit.org/changeset/116160> All reviewed patches have been landed. Closing bug. |