1202666 - http upload stream mishandled during redirects when service worker is controlling the document

Status: RESOLVED DUPLICATE of bug 1093357

(Core :: DOM: Service Workers, defect)

Description

[Ben Kelly [:bkelly, not reviewing]]

Currently the code in HttpBaseChannel and nsHttpChannel attempts to rewind the upload stream using the nsISeekableStream interface.  This is necessary to properly handle redirects where the upload must be reposted to a new URL.

This probably breaks when service workers are enabled because the ServiceWorkerManager clones the upload stream.  If the upload stream was originally something like a file backed blob, then the clone will produce an nsPipe for the upload stream.  Since nsPipe does not support the nsISeekableStream interface the upload will not be properly posted during the redirect.

We probably need to try cloning the stream if the nsISeekableStream interface is not available.

This is a bit of an edge case, but I'd like to fix all the upload stream issues while I'm here working on it.

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Actually, I already see this when running my file-backed blob test in bug 1093357:

[47322] ###!!! ASSERTION: nsPipeInputStream::Seek: 'Not Reached', file /srv/mozilla-central/xpcom/io/nsPipe3.cpp, line 1384
#01: mozilla::net::HttpBaseChannel::SetupReplacementChannel(nsIURI*, nsIChannel*, bool) (/srv/mozilla-central/netwerk/protocol/http/HttpBaseChannel.cpp:2314)
#02: mozilla::net::nsHttpChannel::SetupReplacementChannel(nsIURI*, nsIChannel*, bool) (/srv/mozilla-central/netwerk/protocol/http/nsHttpChannel.cpp:4543)
#03: mozilla::net::nsHttpChannel::StartRedirectChannelToURI(nsIURI*, unsigned int) (/srv/mozilla-central/netwerk/protocol/http/nsHttpChannel.cpp:1976)
#04: mozilla::net::InterceptedChannelChrome::ResetInterception() (/srv/mozilla-central/netwerk/protocol/http/InterceptedChannel.cpp:155)
#05: mozilla::dom::workers::FetchEventRunnable::ResumeRequest::Run() (/srv/mozilla-central/dom/workers/ServiceWorkerManager.cpp:3778)
#06: nsThread::ProcessNextEvent(bool, bool*) (/srv/mozilla-central/xpcom/threads/nsThread.cpp:874)
#07: NS_ProcessNextEvent(nsIThread*, bool) (/srv/mozilla-central/xpcom/glue/nsThreadUtils.cpp:277)
#08: mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (/srv/mozilla-central/ipc/glue/MessagePump.cpp:127)
#09: MessageLoop::RunInternal() (/srv/mozilla-central/ipc/chromium/src/base/message_loop.cc:235)
#10: ~AutoRunState (/srv/mozilla-central/ipc/chromium/src/base/message_loop.cc:520)
#11: nsBaseAppShell::Run() (/srv/mozilla-central/widget/nsBaseAppShell.cpp:158)
#12: nsAppStartup::Run() (/srv/mozilla-central/toolkit/components/startup/nsAppStartup.cpp:282)
#13: XREMain::XRE_mainRun() (/srv/mozilla-central/toolkit/xre/nsAppRunner.cpp:4293)
#14: XREMain::XRE_main(int, char**, nsXREAppData const*) (/srv/mozilla-central/toolkit/xre/nsAppRunner.cpp:4389)

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

I'm just going to fix this as part of bug 1093357.