gecko-dev/netwerk/base/nsIUploadChannel2.idl
Nika Layzell 76b98a65e4 Bug 1754004 - Part 7: Consistently normalize upload streams passed to HTTP channels, r=asuth,necko-reviewers,dragana
Unfortunately, upload streams used by necko have various odd behaviours
and requirements which happened to be usually preserved by the previous
IPC serialization logic, but were not consistently preserved. This
includes requiring the stream to be synchronous (as some consumers such
as WebExtensions and DevTools appear to read it assuming Available() is
the stream length), seekable (as it needs to be rewound in various
places), and cloneable (as the stream information is often handed out to
other components).

In addition, the WebExtension WebRequest code makes assumptions about
the specific topology of the input stream for optimization purposes,
meaning that nsMultiplexInputStreams need to be preserved.

The way this was previously handled was by copying the entire payload
into a nsStorageStream as an async operation. This happened very
infrequently in out test suite, however, and had some issues. It could
lead to data loss if the stream was a nsMIMEInputStream (as the metadata
would be lost), and would destroy the topology required by WebRequest.

This patch changes the code to instead manually walk and replace streams
in the input stream's data structure, to efficiently copy only the
required data, preserve the invariants, and make the type seekable
before AsyncOpen continues. This helps keep the complexity of the
invariants HTTPChannel depends on out of generic input stream handling
code.

In addition, due to how early this happens, it replaces the need for
PartiallySeekableInputStream which will be removed a later part.

Differential Revision: https://phabricator.services.mozilla.com/D141044
2022-05-13 14:16:11 +00:00

58 lines
2.3 KiB
Plaintext

/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#include "nsISupports.idl"
interface nsIInputStream;
interface nsIRunnable;
[scriptable, uuid(2f712b52-19c5-4e0c-9e8f-b5c7c3b67049)]
interface nsIUploadChannel2 : nsISupports
{
/**
* Sets a stream to be uploaded by this channel with the specified
* Content-Type and Content-Length header values.
*
* Most implementations of this interface require that the stream:
* (1) implement threadsafe addRef and release
* (2) implement nsIInputStream::readSegments
* (3) implement nsISeekableStream::seek
*
* @param aStream
* The stream to be uploaded by this channel.
* @param aContentType
* This value will replace any existing Content-Type
* header on the HTTP request, regardless of whether
* or not its empty.
* @param aContentLength
* A value of -1 indicates that the length of the stream should be
* determined by calling the stream's |available| method.
* @param aMethod
* The HTTP request method to set on the stream.
* @param aStreamHasHeaders
* True if the stream already contains headers for the HTTP request.
*/
void explicitSetUploadStream(in nsIInputStream aStream,
in ACString aContentType,
in long long aContentLength,
in ACString aMethod,
in boolean aStreamHasHeaders);
/**
* Value of aStreamHasHeaders from the last successful call to
* explicitSetUploadStream. TRUE indicates the attached upload stream
* contains request headers.
*/
readonly attribute boolean uploadStreamHasHeaders;
/**
* Clones the upload stream. May only be called in the parent process.
* aContentLength could be -1 in case the size of the stream is unknown,
* otherwise it will contain the known size of the stream.
*/
[noscript]
nsIInputStream cloneUploadStream(out long long aContentLength);
};