WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
114480
REGRESSION (
r141136
): Wiki "Random article" function very broken
https://bugs.webkit.org/show_bug.cgi?id=114480
Summary
REGRESSION (r141136): Wiki "Random article" function very broken
Brady Eidson
Reported
2013-04-11 16:55:54 PDT
REGRESSION (
r141136
): Wiki "Random article" function very broken When main resources are in the memory cache, they are keyed off
http://en.wikipedia.org/wiki/Special:Random
Even though
http://en.wikipedia.org/wiki/Special:Random
redirects to a random article each time. So we start to revalidate the resource with wikipedia, and it redirects the revalidation request. In our new redirect request, we still issue a conditional GET to try to revalidate the new request, and that gives us back a 304. So we update our URLs but use the main resource text from the previous article. If the redirect URL differs from the CachedResource we're trying to revalidate, we should stop trying to revalidate and issue an unconditional GET. In radar as <
rdar://problem/13229985
>
Attachments
Patch v1
(17.38 KB, patch)
2013-04-12 16:58 PDT
,
Brady Eidson
ap
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Brady Eidson
Comment 1
2013-04-12 16:58:02 PDT
Created
attachment 197910
[details]
Patch v1 Still making sure I didn't break any other layout tests, but this is my plan.
Alexey Proskuryakov
Comment 2
2013-04-12 21:18:57 PDT
Comment on
attachment 197910
[details]
Patch v1 View in context:
https://bugs.webkit.org/attachment.cgi?id=197910&action=review
Does SubresourceLoader cover all the resources that may be affected?
> Source/WebCore/loader/SubresourceLoader.cpp:137 > + // If this redirect takes us somewhere besides the final response URL of the resource we're revalidating, > + // then make this an unconditional GET request.
I think that this "what" comment adds some value, but a "why" one would be even better.
Brady Eidson
Comment 3
2013-04-12 21:52:34 PDT
(In reply to
comment #2
)
> (From update of
attachment 197910
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=197910&action=review
> > Does SubresourceLoader cover all the resources that may be affected?
SubresourceLoader is the only thing that revalidates CachedResources, so it's an appropriate catch-all for accidentally reusing previously loaded resources.
> > Source/WebCore/loader/SubresourceLoader.cpp:137 > > + // If this redirect takes us somewhere besides the final response URL of the resource we're revalidating, > > + // then make this an unconditional GET request. > > I think that this "what" comment adds some value, but a "why" one would be even better.
I can definitely improve this.
Brady Eidson
Comment 4
2013-04-22 16:26:18 PDT
EWS never churned all the way through this, and running tests locally is proving to be a hit-or-miss PITA. I need to move forward with this one and watch the actual testers afterwards.
Brady Eidson
Comment 5
2013-04-22 16:27:59 PDT
http://trac.webkit.org/changeset/148929
Brady Eidson
Comment 6
2013-04-22 16:30:14 PDT
(In reply to
comment #3
)
> (In reply to
comment #2
) > > > Source/WebCore/loader/SubresourceLoader.cpp:137 > > > + // If this redirect takes us somewhere besides the final response URL of the resource we're revalidating, > > > + // then make this an unconditional GET request. > > > > I think that this "what" comment adds some value, but a "why" one would be even better. > > I can definitely improve this.
Since I'd worked on other things for ~9 days, I forgot to address this comment. My apologies. Will fix in a followup
Brady Eidson
Comment 7
2013-04-22 16:41:26 PDT
Followed up in
http://trac.webkit.org/changeset/148932
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug