WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
133483
[Curl] Empty headers in request response.
https://bugs.webkit.org/show_bug.cgi?id=133483
Summary
[Curl] Empty headers in request response.
peavo
Reported
2014-06-03 09:51:09 PDT
When a request is taken from the cache, it's cached response headers are empty, if the cache entry was created in the same session. It is only when the cache entry is loaded from disc, that the response headers are properly set. We need to set the cached response headers in both cases. There is also an issue if two jobs are loading the same url at the same time. Both jobs will then write to the cache content file, and create invalid content. This can be fixed by only letting the first request write to the content file.
Attachments
Patch
(12.25 KB, patch)
2014-06-03 10:11 PDT
,
peavo
no flags
Details
Formatted Diff
Diff
Patch
(12.49 KB, patch)
2014-06-05 08:59 PDT
,
peavo
no flags
Details
Formatted Diff
Diff
Patch
(12.48 KB, patch)
2014-06-05 12:41 PDT
,
peavo
no flags
Details
Formatted Diff
Diff
Patch
(14.69 KB, patch)
2014-06-06 09:04 PDT
,
peavo
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
peavo
Comment 1
2014-06-03 10:11:00 PDT
Created
attachment 232431
[details]
Patch
Alex Christensen
Comment 2
2014-06-04 23:41:12 PDT
You should add checks to see if job is null before dereferencing it. Are raw pointers really the best thing to use here?
peavo
Comment 3
2014-06-05 08:59:54 PDT
Created
attachment 232553
[details]
Patch
peavo
Comment 4
2014-06-05 09:00:53 PDT
(In reply to
comment #2
)
> You should add checks to see if job is null before dereferencing it. Are raw pointers really the best thing to use here?
Thanks for looking into this :) Added null pointer checks.
Alex Christensen
Comment 5
2014-06-05 10:05:16 PDT
Comment on
attachment 232553
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=232553&action=review
> Source/WebCore/ChangeLog:13 > + This can be fixed by only letting the first request write to the content file.
Does this also protect against another process writing to the file?
> Source/WebCore/platform/network/curl/CurlCacheManager.cpp:142 > + std::unique_ptr<CurlCacheEntry> cacheEntry(new CurlCacheEntry(url, 0, m_cacheDir));
This 0 should be a nullptr. Also, try using std::make_unique instead of new.
> Source/WebCore/platform/network/curl/CurlCacheManager.cpp:219 > + std::unique_ptr<CurlCacheEntry> cacheEntry(new CurlCacheEntry(url, job, m_cacheDir));
make_unique
peavo
Comment 6
2014-06-05 12:41:01 PDT
Created
attachment 232573
[details]
Patch
peavo
Comment 7
2014-06-05 12:43:27 PDT
(In reply to
comment #5
)
> (From update of
attachment 232553
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=232553&action=review
> > > Source/WebCore/ChangeLog:13 > > + This can be fixed by only letting the first request write to the content file. > > Does this also protect against another process writing to the file?
> No, I don't believe it's designed to handle access by multiple processes.
> > Source/WebCore/platform/network/curl/CurlCacheManager.cpp:142 > > + std::unique_ptr<CurlCacheEntry> cacheEntry(new CurlCacheEntry(url, 0, m_cacheDir)); > > This 0 should be a nullptr. Also, try using std::make_unique instead of new. > > > Source/WebCore/platform/network/curl/CurlCacheManager.cpp:219 > > + std::unique_ptr<CurlCacheEntry> cacheEntry(new CurlCacheEntry(url, job, m_cacheDir)); > > make_unique
Done.
Alex Christensen
Comment 8
2014-06-05 16:17:48 PDT
This looks good to me, but a reviewer will have to r+ it.
Brent Fulgham
Comment 9
2014-06-05 22:32:55 PDT
Comment on
attachment 232573
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=232573&action=review
I think this looks good, but it could be made a bit tighter.
> Source/WebCore/platform/network/curl/CurlCacheEntry.cpp:48 > +CurlCacheEntry::CurlCacheEntry(const String& url, ResourceHandle* job, const String& cacheDir)
This could be a reference...
> Source/WebCore/platform/network/curl/CurlCacheEntry.h:64 > + const ResourceHandle* getJob() const { return m_job; }
This could then return a reference...
> Source/WebCore/platform/network/curl/CurlCacheEntry.h:80 > + ResourceHandle* m_job;
This could just be a const reference, since m_job doesn't appear to be allowed to be null, does it?
> Source/WebCore/platform/network/curl/CurlCacheManager.cpp:142 > + std::unique_ptr<CurlCacheEntry> cacheEntry = std::make_unique<CurlCacheEntry>(url, nullptr, m_cacheDir);
auto cacheEntry!
> Source/WebCore/platform/network/curl/CurlCacheManager.cpp:213 > + HashMap<String, std::unique_ptr<CurlCacheEntry>>::iterator it = m_index.find(url);
This would be better as auto to avoid having to type all that stuff out.
> Source/WebCore/platform/network/curl/CurlCacheManager.cpp:219 > + std::unique_ptr<CurlCacheEntry> cacheEntry = std::make_unique<CurlCacheEntry>(url, job, m_cacheDir);
auto cacheEntry
> Source/WebCore/platform/network/curl/CurlCacheManager.cpp:230 > +void CurlCacheManager::didFinishLoading(ResourceHandle* job)
Make this a ResourceHandle& ...
> Source/WebCore/platform/network/curl/CurlCacheManager.cpp:236 > + return;
... and get rid of this null check!
> Source/WebCore/platform/network/curl/CurlCacheManager.cpp:276 > +void CurlCacheManager::didReceiveData(ResourceHandle* job, const char* data, size_t size)
Make this a reference ...
> Source/WebCore/platform/network/curl/CurlCacheManager.cpp:282 > + return;
... and get rid of this null check.
> Source/WebCore/platform/network/curl/CurlCacheManager.cpp:331 > +void CurlCacheManager::didFail(ResourceHandle *job)
Make this a reference ...
> Source/WebCore/platform/network/curl/CurlCacheManager.cpp:334 > + return;
... and get rid of this null check.
> Source/WebCore/platform/network/curl/CurlCacheManager.h:55 > + void didFail(ResourceHandle*);
These could all be (const ResourceHandle&), since 'job' is never NULL in the use cases you are changing.
> Source/WebCore/platform/network/curl/ResourceHandleManager.cpp:328 > + CurlCacheManager::getInstance().didReceiveData(job, static_cast<char*>(ptr), totalSize);
'job' was always non-null here, so why not pass it as a reference?
> Source/WebCore/platform/network/curl/ResourceHandleManager.cpp:692 > + CurlCacheManager::getInstance().didFinishLoading(job);
ditto: 'job' was always non-null here, so why not pass it as a reference?
> Source/WebCore/platform/network/curl/ResourceHandleManager.cpp:704 > + CurlCacheManager::getInstance().didFail(job);
ditto: 'job' was always non-null here, so why not pass it as a reference?
peavo
Comment 10
2014-06-06 09:04:04 PDT
Created
attachment 232615
[details]
Patch
peavo
Comment 11
2014-06-06 09:12:46 PDT
(In reply to
comment #9
)
> (From update of
attachment 232573
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=232573&action=review
>
Thanks for reviewing :)
> I think this looks good, but it could be made a bit tighter. > > > Source/WebCore/platform/network/curl/CurlCacheEntry.cpp:48 > > +CurlCacheEntry::CurlCacheEntry(const String& url, ResourceHandle* job, const String& cacheDir) > > This could be a reference... > > > Source/WebCore/platform/network/curl/CurlCacheEntry.h:64 > > + const ResourceHandle* getJob() const { return m_job; } > > This could then return a reference... > > > Source/WebCore/platform/network/curl/CurlCacheEntry.h:80 > > + ResourceHandle* m_job; > > This could just be a const reference, since m_job doesn't appear to be allowed to be null, does it? >
I left this as is, since m_job will be null if the entry is loaded from disc, there will be no associated job then.
> > Source/WebCore/platform/network/curl/CurlCacheManager.cpp:142 > > + std::unique_ptr<CurlCacheEntry> cacheEntry = std::make_unique<CurlCacheEntry>(url, nullptr, m_cacheDir); > > auto cacheEntry! > > > Source/WebCore/platform/network/curl/CurlCacheManager.cpp:213 > > + HashMap<String, std::unique_ptr<CurlCacheEntry>>::iterator it = m_index.find(url); > > This would be better as auto to avoid having to type all that stuff out. > > > Source/WebCore/platform/network/curl/CurlCacheManager.cpp:219 > > + std::unique_ptr<CurlCacheEntry> cacheEntry = std::make_unique<CurlCacheEntry>(url, job, m_cacheDir); > > auto cacheEntry > > > Source/WebCore/platform/network/curl/CurlCacheManager.cpp:230 > > +void CurlCacheManager::didFinishLoading(ResourceHandle* job) > > Make this a ResourceHandle& ... > > > Source/WebCore/platform/network/curl/CurlCacheManager.cpp:236 > > + return; > > ... and get rid of this null check! > > > Source/WebCore/platform/network/curl/CurlCacheManager.cpp:276 > > +void CurlCacheManager::didReceiveData(ResourceHandle* job, const char* data, size_t size) >
Done.
Brent Fulgham
Comment 12
2014-06-11 09:56:03 PDT
Comment on
attachment 232615
[details]
Patch r=me
WebKit Commit Bot
Comment 13
2014-06-11 10:28:01 PDT
Comment on
attachment 232615
[details]
Patch Clearing flags on attachment: 232615 Committed
r169811
: <
http://trac.webkit.org/changeset/169811
>
WebKit Commit Bot
Comment 14
2014-06-11 10:28:04 PDT
All reviewed patches have been landed. Closing bug.
peavo
Comment 15
2014-06-11 10:52:01 PDT
(In reply to
comment #12
)
> (From update of
attachment 232615
[details]
) > r=me
Thanks!
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