Bug 165120 – Web Inspector: Null ResourceResponse Preflight requests cause crash

• Component: Web Inspector
• Status: RESOLVED FIXED

[Joseph Pecoraro]

Summary:
Null ResourceResponse Preflight requests cause crash

Crash:
Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.JavaScriptCore      	0x00000001021ddb66 Inspector::InspectorObjectBase::writeJSON(WTF::StringBuilder&) const + 342
1   com.apple.JavaScriptCore      	0x00000001021ddb6f Inspector::InspectorObjectBase::writeJSON(WTF::StringBuilder&) const + 351
2   com.apple.JavaScriptCore      	0x00000001021dcab3 Inspector::InspectorValue::toJSONString() const + 83
3   com.apple.JavaScriptCore      	0x00000001021cbdf8 Inspector::NetworkFrontendDispatcher::responseReceived(WTF::String const&, WTF::String const&, WTF::String const&, double, Inspector::Protocol::Page::ResourceType, WTF::RefPtr<Inspector::Protocol::Network::Response>) + 2136
4   com.apple.WebCore             	0x0000000103107693 WebCore::InspectorNetworkAgent::didReceiveResponse(unsigned long, WebCore::DocumentLoader&, WebCore::ResourceResponse const&, WebCore::ResourceLoader*) + 995
5   com.apple.WebCore             	0x00000001029c3901 WebCore::InspectorInstrumentation::didReceiveResourceResponseImpl(WebCore::InspectorInstrumentationCookie const&, unsigned long, WebCore::DocumentLoader*, WebCore::ResourceResponse const&, WebCore::ResourceLoader*) + 49
6   com.apple.WebCore             	0x0000000102d21bd5 WebCore::CrossOriginPreflightChecker::validatePreflightResponse(WebCore::DocumentThreadableLoader&, WebCore::ResourceRequest&&, unsigned long, WebCore::ResourceResponse const&) + 117
7   com.apple.WebCore             	0x00000001029de379 WebCore::CachedResource::checkNotify() + 153
8   com.apple.WebCore             	0x0000000102c8a430 WebCore::CachedRawResource::finishLoading(WebCore::SharedBuffer*) + 224
9   com.apple.WebCore             	0x00000001029de1ab WebCore::SubresourceLoader::didFinishLoading(double) + 1163
10  com.apple.WebCore             	0x00000001038f6526 WebCore::SubresourceLoader::willSendRequestInternal(WebCore::ResourceRequest&, WebCore::ResourceResponse const&) + 694
11  com.apple.WebCore             	0x00000001037a41a6 WebCore::ResourceLoader::willSendRequest(WebCore::ResourceRequest&&, WebCore::ResourceResponse const&, std::__1::function<void (WebCore::ResourceRequest&&)>&&) + 22
12  com.apple.WebKit              	0x000000010141f7ca WebKit::WebResourceLoader::willSendRequest(WebCore::ResourceRequest&&, WebCore::ResourceResponse&&) + 148
...

Notes:
- Unsure how to reproduce.
- Crashes always have CrossOriginPreflightChecker::validatePreflightResponse => NetworkFrontendDispatcher::responseReceived
- InspectorValue::toJSONString choking on a NULL value here means that the ResourceResponse given to InspectorInstrumentation was a "null response"

[Joseph Pecoraro]

<rdar://problem/27911350>

[Joseph Pecoraro]

Created attachment 295545 [details]
[PATCH] Proposed Fix

[Joseph Pecoraro]

Youeen if you have any ideas how we can get a Null Response here, please provide pointers and I can try and add a LayoutTest to cover it. The LayoutTests (http/tests/xmlhttprequest) seem to cover quite a few cases, and even after reading the code I'm unsure how we could get a Null response here without the Request being a failure or cancelled.

[Joseph Pecoraro]

For these crashes to happen Web Inspector would have to have been open, otherwise we wouldn't get into WebCore::InspectorNetworkAgent at all.

[Daniel Bates]

Have you tested with a CORS preflight request that is redirected?

[Daniel Bates]

(In reply to comment #5)
> Have you tested with a CORS preflight request that is redirected?

When handling such a case we get here <http://trac.webkit.org/browser/trunk/Source/WebCore/loader/SubresourceLoader.cpp?rev=208919#L190>.

[Joseph Pecoraro]

(In reply to comment #5)
> Have you tested with a CORS preflight request that is redirected?

I ran a LayoutTest that should cover this with Web Inspector open and didn't encounter any issues:
http://127.0.0.1:8000/xmlhttprequest/redirections-and-user-headers.html

However looking at that code:

>    ResourceResponse opaqueRedirectedResponse;
>    opaqueRedirectedResponse.setURL(redirectResponse.url());
>    opaqueRedirectedResponse.setType(ResourceResponse::Type::Opaqueredirect);
>    m_resource->responseReceived(opaqueRedirectedResponse);

ResourceResponseBase::setURL would make this response non-null.

I'll try putting an early ASSERT in and seeing if a Debug build can catch this with any LayoutTests.

[youenn fablet]

Preflight requests redirect fetch mode is set to Manual so that no redirection is followed.
For simplicity and efficiency currently, we return a null response at the "application level" (i.e. the preflight checker).

But it seems useful to pass the information to the inspector (and service worker in the future). So maybe we should make a copy of the redirect response in manual-redirect mode, still setting the response type to opaqueRedirect.

[Blaze Burg]

Comment on attachment 295545 [details]
[PATCH] Proposed Fix

r=me

[WebKit Commit Bot]

Comment on attachment 295545 [details]
[PATCH] Proposed Fix

Clearing flags on attachment: 295545

Committed r209134: <http://trac.webkit.org/changeset/209134>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.