2018-05-31 19:12:25 +03:00
|
|
|
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
|
|
|
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
|
|
|
|
/* 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/. */
|
|
|
|
|
|
|
|
#ifndef InputStreamLengthWrapper_h
|
|
|
|
#define InputStreamLengthWrapper_h
|
|
|
|
|
|
|
|
#include "mozilla/Attributes.h"
|
|
|
|
#include "mozilla/Mutex.h"
|
|
|
|
#include "nsCOMPtr.h"
|
|
|
|
#include "nsIAsyncInputStream.h"
|
|
|
|
#include "nsICloneableInputStream.h"
|
|
|
|
#include "nsIIPCSerializableInputStream.h"
|
|
|
|
#include "nsISeekableStream.h"
|
|
|
|
#include "nsIInputStreamLength.h"
|
|
|
|
|
|
|
|
namespace mozilla {
|
|
|
|
|
|
|
|
// A wrapper keeps an inputStream together with its length.
|
|
|
|
// This class can be used for nsIInputStreams that do not implement
|
|
|
|
// nsIInputStreamLength.
|
|
|
|
|
|
|
|
class InputStreamLengthWrapper final : public nsIAsyncInputStream,
|
|
|
|
public nsICloneableInputStream,
|
|
|
|
public nsIIPCSerializableInputStream,
|
|
|
|
public nsISeekableStream,
|
|
|
|
public nsIInputStreamCallback,
|
|
|
|
public nsIInputStreamLength {
|
|
|
|
public:
|
|
|
|
NS_DECL_THREADSAFE_ISUPPORTS
|
|
|
|
NS_DECL_NSIINPUTSTREAM
|
|
|
|
NS_DECL_NSIASYNCINPUTSTREAM
|
|
|
|
NS_DECL_NSICLONEABLEINPUTSTREAM
|
|
|
|
NS_DECL_NSIIPCSERIALIZABLEINPUTSTREAM
|
|
|
|
NS_DECL_NSISEEKABLESTREAM
|
Bug 1496581 - Split nsISeekableStream in 2 classes: nsISeekableStream and nsITellableStream, f=mayhemer, r=froydnj
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.
2018-10-18 14:35:35 +03:00
|
|
|
NS_DECL_NSITELLABLESTREAM
|
2018-05-31 19:12:25 +03:00
|
|
|
NS_DECL_NSIINPUTSTREAMCALLBACK
|
|
|
|
NS_DECL_NSIINPUTSTREAMLENGTH
|
|
|
|
|
2018-06-13 18:37:26 +03:00
|
|
|
// This method creates a InputStreamLengthWrapper around aInputStream if
|
|
|
|
// this doesn't implement nsIInputStreamLength or
|
|
|
|
// nsIInputStreamAsyncLength interface, but it implements
|
|
|
|
// nsIAsyncInputStream. For this kind of streams,
|
|
|
|
// InputStreamLengthHelper is not able to retrieve the length. This
|
|
|
|
// method will make such streams ready to be used with
|
|
|
|
// InputStreamLengthHelper.
|
|
|
|
static already_AddRefed<nsIInputStream> MaybeWrap(
|
|
|
|
already_AddRefed<nsIInputStream> aInputStream, int64_t aLength);
|
|
|
|
|
2018-05-31 19:12:25 +03:00
|
|
|
// The length here will be used when nsIInputStreamLength::Length() is called.
|
|
|
|
InputStreamLengthWrapper(already_AddRefed<nsIInputStream> aInputStream,
|
|
|
|
int64_t aLength);
|
|
|
|
|
|
|
|
// This CTOR is meant to be used just for IPC.
|
|
|
|
InputStreamLengthWrapper();
|
|
|
|
|
|
|
|
private:
|
|
|
|
~InputStreamLengthWrapper();
|
|
|
|
|
2019-01-28 12:48:35 +03:00
|
|
|
template <typename M>
|
|
|
|
void SerializeInternal(mozilla::ipc::InputStreamParams& aParams,
|
|
|
|
FileDescriptorArray& aFileDescriptors,
|
2019-02-05 01:50:51 +03:00
|
|
|
bool aDelayedStart, uint32_t aMaxSize,
|
|
|
|
uint32_t* aSizeUsed, M* aManager);
|
2019-01-28 12:48:35 +03:00
|
|
|
|
2018-05-31 19:12:25 +03:00
|
|
|
void SetSourceStream(already_AddRefed<nsIInputStream> aInputStream);
|
|
|
|
|
|
|
|
nsCOMPtr<nsIInputStream> mInputStream;
|
|
|
|
|
|
|
|
// Raw pointers because these are just QI of mInputStream.
|
|
|
|
nsICloneableInputStream* mWeakCloneableInputStream;
|
|
|
|
nsIIPCSerializableInputStream* mWeakIPCSerializableInputStream;
|
|
|
|
nsISeekableStream* mWeakSeekableInputStream;
|
Bug 1496581 - Split nsISeekableStream in 2 classes: nsISeekableStream and nsITellableStream, f=mayhemer, r=froydnj
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.
2018-10-18 14:35:35 +03:00
|
|
|
nsITellableStream* mWeakTellableInputStream;
|
2018-05-31 19:12:25 +03:00
|
|
|
nsIAsyncInputStream* mWeakAsyncInputStream;
|
|
|
|
|
|
|
|
int64_t mLength;
|
|
|
|
bool mConsumed;
|
|
|
|
|
|
|
|
mozilla::Mutex mMutex;
|
|
|
|
|
|
|
|
// This is used for AsyncWait and it's protected by mutex.
|
|
|
|
nsCOMPtr<nsIInputStreamCallback> mAsyncWaitCallback;
|
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace mozilla
|
|
|
|
|
|
|
|
#endif // InputStreamLengthWrapper_h
|