With the old process selector service implementation, non-cached loads
would skip the call into the process selector.
This implementation piggybacks atop the existing 'redirectTo' mechanism.
This is unfortunately not the perfect system for catching these loads,
as it doesn't provide an opportunity for performing a final process
switch before redirecting to a non-http channel. In addition, it doesn't
provide indication that a redirect is going to happen, causing
potentially unnecessary process switches.
Not all places where 'redirectTo' is supported use this mechanism. This
process switching mechanism is only checked in situations after
http-on-examine-response.
Potential future changes include:
1. Moving these checks closer to the real 'OnStartRequest' call (e.g.
in ContinueProcessNormal + ContinueOnStartRequest3). This would mean
that loads other than the final load will not cause process swaps.
2. Adding a callback before a redirect is performed, passing in the new
channel, and allowing modifications to be made. This would allow
performing a process swap before redirecting to a non-http(s)
channel.
Depends on D15609
Differential Revision: https://phabricator.services.mozilla.com/D15610
For navigation: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
For images: image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5
for style: text/css,*/*;q=0.1
Anything else: */*
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
WPT parses HTTP log and create a HAR file. To reduce the overhead of logging, this patch moves some logs that are used by WPT parser to level 1.
Differential Revision: https://phabricator.services.mozilla.com/D8986
Necko does not allow for a CONNECT only request to happen. This adds a flag
to signal an http channel should only CONNECT if proxied. This flag can only be
set if an HTTPUpgrade handler has been assigned. As proposed by rfc7639, an
alpn header will be included in the CONNECT request. Its value is determined by
the upgrade protocol passed to HTTPUpgrade.
The flag is added as part of nsIHttpChannelInternal because it is dependent on
HTTPUpgrade. It exists as a capability flag since the channel's transaction
needs to know to complete after a successful CONNECT. Also the transaction's
connection needs to know to stop writing transaction data after it CONNECTs or
if there's no proxy, and to not tell the transaction to reset.
If an nsHttpChannel has this flag set then the upgrade handler will receive the
socket after the CONNECT succeeds without doing tls if https.
In order to support xpcshell-test for this change, nsHttpConnectionMgr does a
little check to see if HTTPUpgrade callback is in JavaScript. If it is then
the callback is invoked on the main thread.
In the current code there are 3 main issues:
1. nsFileStream is not really thread-safe. There is nothing to protect the
internal members and we see crashes.
2. nsPipeInputStream doesn't implement ::Seek() method and that caused issues
in devtools when a nsHttpChannel sends POST data using a pipe. In order to fix
this, bug 1494176 added a check in nsHttpChannel: if the stream doesn't
implement ::Seek(), let's clone it. This was an hack around nsPipeInputStream,
and it's bad.
3. When nsHttpChannel sends POST data using a file stream, nsFileStream does
I/O on main-thread because of the issue 2. Plus, ::Seek() is called on the
main-thread causing issue 1.
Note that nsPipeInputStream implements only ::Tell(), of the nsISeekableStream
methods. It doesn't implement ::Seek() and it doesn't implement ::SetEOF().
With this patch I want to fix point 2 and point 3 (and consequentially issue 1
- but we need a separate fix for it - follow up). The patch does:
1. it splits nsISeekableStream in 2 interfaces: nsITellableStream and
nsISeekableStream.
2. nsPipeInputStream implements only nsITellableStream. Doing this, we don't
need the ::Seek() check for point 2 in nsHttpChannel: a simple QI check is
enough.
3. Because we don't call ::Seek() in nsHttpChannel, nsFileStream doesn't do I/O
on the main-thread, and we don't crash doing so.
This patch changes the way we set and handle the preferred alternate data type.
It is no longer just one choice, but a set of preferences, each conditional
on the contentType of the resource.
For example:
var cc = chan.QueryInterface(Ci.nsICacheInfoChannel);
cc.preferAlternativeDataType("js-bytecode", "text/javascript");
cc.preferAlternativeDataType("ammended-text", "text/plain");
cc.preferAlternativeDataType("something-else", "");
When loaded from the cache, the available alt-data type will be checked against
"js-bytecode" if the contentType is "text/javascript", "ammended-text" if the contentType is "text/plain" or "something-else" for all contentTypes.
Note that the alt-data type could be "something-else" even if the contentType is "text/javascript".
The preferences are saved as an nsTArray<mozilla::Tuple<nsCString, nsCString>>.
Differential Revision: https://phabricator.services.mozilla.com/D8071
This patch changes the way we set and handle the preferred alternate data type.
It is no longer just one choice, but a set of preferences, each conditional
on the contentType of the resource.
For example:
var cc = chan.QueryInterface(Ci.nsICacheInfoChannel);
cc.preferAlternativeDataType("js-bytecode", "text/javascript");
cc.preferAlternativeDataType("ammended-text", "text/plain");
cc.preferAlternativeDataType("something-else", "");
When loaded from the cache, the available alt-data type will be checked against
"js-bytecode" if the contentType is "text/javascript", "ammended-text" if the contentType is "text/plain" or "something-else" for all contentTypes.
Note that the alt-data type could be "something-else" even if the contentType is "text/javascript".
The preferences are saved as an nsTArray<mozilla::Tuple<nsCString, nsCString>>.
Differential Revision: https://phabricator.services.mozilla.com/D8071
