2014-06-30 19:39:45 +04: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: */
|
2012-05-21 15:12:37 +04:00
|
|
|
/* 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/. */
|
2001-11-22 02:55:10 +03:00
|
|
|
|
|
|
|
#ifndef nsStringStream_h__
|
|
|
|
#define nsStringStream_h__
|
|
|
|
|
|
|
|
#include "nsIStringStream.h"
|
2017-12-07 03:52:51 +03:00
|
|
|
#include "nsString.h"
|
2006-01-02 05:30:32 +03:00
|
|
|
#include "nsMemory.h"
|
2001-11-22 02:55:10 +03:00
|
|
|
|
|
|
|
/**
|
2006-01-10 04:56:00 +03:00
|
|
|
* Implements:
|
|
|
|
* nsIStringInputStream
|
|
|
|
* nsIInputStream
|
|
|
|
* 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
|
|
|
* nsITellableStream
|
2006-03-11 00:38:02 +03:00
|
|
|
* nsISupportsCString
|
2001-11-22 02:55:10 +03:00
|
|
|
*/
|
|
|
|
#define NS_STRINGINPUTSTREAM_CONTRACTID "@mozilla.org/io/string-input-stream;1"
|
|
|
|
#define NS_STRINGINPUTSTREAM_CID \
|
|
|
|
{ /* 0abb0835-5000-4790-af28-61b3ba17c295 */ \
|
|
|
|
0x0abb0835, \
|
|
|
|
0x5000, \
|
|
|
|
0x4790, \
|
|
|
|
{0xaf, 0x28, 0x61, 0xb3, 0xba, 0x17, 0xc2, 0x95} \
|
|
|
|
}
|
|
|
|
|
2006-01-02 05:30:32 +03:00
|
|
|
/**
|
|
|
|
* Factory method to get an nsInputStream from a byte buffer. Result will
|
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
|
|
|
* implement nsIStringInputStream, nsITellableStream and nsISeekableStream.
|
2006-01-02 05:30:32 +03:00
|
|
|
*
|
|
|
|
* If aAssignment is NS_ASSIGNMENT_COPY, then the resulting stream holds a copy
|
|
|
|
* of the given buffer (aStringToRead), and the caller is free to discard
|
|
|
|
* aStringToRead after this function returns.
|
|
|
|
*
|
|
|
|
* If aAssignment is NS_ASSIGNMENT_DEPEND, then the resulting stream refers
|
|
|
|
* directly to the given buffer (aStringToRead), so the caller must ensure that
|
|
|
|
* the buffer remains valid for the lifetime of the stream object. Use with
|
|
|
|
* care!!
|
|
|
|
*
|
|
|
|
* If aAssignment is NS_ASSIGNMENT_ADOPT, then the resulting stream refers
|
|
|
|
* directly to the given buffer (aStringToRead) and will free aStringToRead
|
|
|
|
* once the stream is closed.
|
|
|
|
*
|
|
|
|
* If aLength is less than zero, then the length of aStringToRead will be
|
|
|
|
* determined by scanning the buffer for the first null byte.
|
|
|
|
*/
|
2011-08-18 17:46:39 +04:00
|
|
|
extern nsresult
|
2006-01-02 05:30:32 +03:00
|
|
|
NS_NewByteInputStream(nsIInputStream** aStreamResult,
|
2012-08-22 19:56:38 +04:00
|
|
|
const char* aStringToRead, int32_t aLength = -1,
|
2006-01-02 05:30:32 +03:00
|
|
|
nsAssignmentType aAssignment = NS_ASSIGNMENT_DEPEND);
|
2003-03-15 04:04:32 +03:00
|
|
|
|
2006-01-02 05:30:32 +03:00
|
|
|
/**
|
|
|
|
* Factory method to get an nsInputStream from an nsACString. Result will
|
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
|
|
|
* implement nsIStringInputStream, nsTellableStream and nsISeekableStream.
|
2006-01-02 05:30:32 +03:00
|
|
|
*/
|
2011-08-18 17:46:39 +04:00
|
|
|
extern nsresult
|
2006-01-02 05:30:32 +03:00
|
|
|
NS_NewCStringInputStream(nsIInputStream** aStreamResult,
|
|
|
|
const nsACString& aStringToRead);
|
2018-04-11 17:06:17 +03:00
|
|
|
extern nsresult
|
|
|
|
NS_NewCStringInputStream(nsIInputStream** aStreamResult,
|
|
|
|
nsCString&& aStringToRead);
|
2003-03-15 04:04:32 +03:00
|
|
|
|
2001-11-22 02:55:10 +03:00
|
|
|
#endif // nsStringStream_h__
|