2018-11-30 22:52:05 +03:00
|
|
|
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
1999-10-26 23:43:26 +04:00
|
|
|
/* nsJARInputStream.cpp
|
2017-07-06 15:00:35 +03:00
|
|
|
*
|
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/. */
|
2003-03-14 21:59:51 +03:00
|
|
|
|
1999-10-26 23:43:26 +04:00
|
|
|
#include "nsJARInputStream.h"
|
2006-05-02 23:33:09 +04:00
|
|
|
#include "zipstruct.h" // defines ZIP compression codes
|
Bug 1355661 - Add support for brotli streams in Jar archives. r=aklotz
Modern compression algorithms are better than zlib both in terms of
space and time. The jar format, used for e.g. omni.ja, addons, etc.
could benefit from using such modern algorithms, but the format only
allows a limited set of compression algorithms.
However, the format in itself is flexible, in that it can be extended
with arbitrary compression algorithms. This breaks compatibility with
programs like unzip, obviously, but we've never promised the files
shipped with Firefox will always remain "valid" zips (which they already
aren't, but they currently work with most zip readers).
With this change, we allow those archives to contain brotli streams,
using an arbitrary large value for the compression type in the Zip local
file header. This only allows to read such archives, but not to produce
them, and, for now, support for brotli streams is kept Nightly-only,
until everything is pieced together and we're happy to ship it.
--HG--
extra : rebase_source : fa637251f460ad0d91d5f5bec392c6e59555e80d
2017-04-07 08:48:25 +03:00
|
|
|
#ifdef MOZ_JAR_BROTLI
|
2017-08-09 13:45:39 +03:00
|
|
|
# include "brotli/decode.h" // brotli
|
Bug 1355661 - Add support for brotli streams in Jar archives. r=aklotz
Modern compression algorithms are better than zlib both in terms of
space and time. The jar format, used for e.g. omni.ja, addons, etc.
could benefit from using such modern algorithms, but the format only
allows a limited set of compression algorithms.
However, the format in itself is flexible, in that it can be extended
with arbitrary compression algorithms. This breaks compatibility with
programs like unzip, obviously, but we've never promised the files
shipped with Firefox will always remain "valid" zips (which they already
aren't, but they currently work with most zip readers).
With this change, we allow those archives to contain brotli streams,
using an arbitrary large value for the compression type in the Zip local
file header. This only allows to read such archives, but not to produce
them, and, for now, support for brotli streams is kept Nightly-only,
until everything is pieced together and we're happy to ship it.
--HG--
extra : rebase_source : fa637251f460ad0d91d5f5bec392c6e59555e80d
2017-04-07 08:48:25 +03:00
|
|
|
#endif
|
1999-10-26 23:43:26 +04:00
|
|
|
#include "nsZipArchive.h"
|
|
|
|
|
2006-10-10 17:24:57 +04:00
|
|
|
#include "nsEscape.h"
|
|
|
|
#include "nsIFile.h"
|
2009-08-13 00:50:12 +04:00
|
|
|
#include "nsDebug.h"
|
2013-01-15 16:22:03 +04:00
|
|
|
#include <algorithm>
|
2010-11-11 23:13:48 +03:00
|
|
|
#if defined(XP_WIN)
|
|
|
|
# include <windows.h>
|
|
|
|
#endif
|
1999-10-26 23:43:26 +04:00
|
|
|
|
|
|
|
/*---------------------------------------------
|
|
|
|
* nsISupports implementation
|
|
|
|
*--------------------------------------------*/
|
|
|
|
|
2014-04-27 11:06:00 +04:00
|
|
|
NS_IMPL_ISUPPORTS(nsJARInputStream, nsIInputStream)
|
1999-10-26 23:43:26 +04:00
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* nsJARInputStream implementation
|
|
|
|
*--------------------------------------------------------*/
|
|
|
|
|
2009-10-04 21:20:45 +04:00
|
|
|
nsresult nsJARInputStream::InitFile(nsJAR *aJar, nsZipItem *item) {
|
|
|
|
nsresult rv = NS_OK;
|
2015-02-10 01:34:50 +03:00
|
|
|
MOZ_ASSERT(aJar, "Argument may not be null");
|
|
|
|
MOZ_ASSERT(item, "Argument may not be null");
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2006-05-02 23:33:09 +04:00
|
|
|
// Mark it as closed, in case something fails in initialisation
|
2009-10-04 21:20:45 +04:00
|
|
|
mMode = MODE_CLOSED;
|
2006-05-02 23:33:09 +04:00
|
|
|
//-- prepare for the compression type
|
2009-10-17 19:54:54 +04:00
|
|
|
switch (item->Compression()) {
|
2017-07-06 15:00:35 +03:00
|
|
|
case STORED:
|
2009-10-04 21:20:45 +04:00
|
|
|
mMode = MODE_COPY;
|
2006-05-02 23:33:09 +04:00
|
|
|
break;
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2006-05-02 23:33:09 +04:00
|
|
|
case DEFLATED:
|
2009-10-04 21:20:45 +04:00
|
|
|
rv = gZlibInit(&mZs);
|
|
|
|
NS_ENSURE_SUCCESS(rv, rv);
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2009-10-04 21:20:45 +04:00
|
|
|
mMode = MODE_INFLATE;
|
2009-10-17 19:54:54 +04:00
|
|
|
mInCrc = item->CRC32();
|
2009-10-04 21:20:45 +04:00
|
|
|
mOutCrc = crc32(0L, Z_NULL, 0);
|
2006-05-02 23:33:09 +04:00
|
|
|
break;
|
|
|
|
|
Bug 1355661 - Add support for brotli streams in Jar archives. r=aklotz
Modern compression algorithms are better than zlib both in terms of
space and time. The jar format, used for e.g. omni.ja, addons, etc.
could benefit from using such modern algorithms, but the format only
allows a limited set of compression algorithms.
However, the format in itself is flexible, in that it can be extended
with arbitrary compression algorithms. This breaks compatibility with
programs like unzip, obviously, but we've never promised the files
shipped with Firefox will always remain "valid" zips (which they already
aren't, but they currently work with most zip readers).
With this change, we allow those archives to contain brotli streams,
using an arbitrary large value for the compression type in the Zip local
file header. This only allows to read such archives, but not to produce
them, and, for now, support for brotli streams is kept Nightly-only,
until everything is pieced together and we're happy to ship it.
--HG--
extra : rebase_source : fa637251f460ad0d91d5f5bec392c6e59555e80d
2017-04-07 08:48:25 +03:00
|
|
|
#ifdef MOZ_JAR_BROTLI
|
|
|
|
case MOZ_JAR_BROTLI:
|
2017-08-09 13:45:39 +03:00
|
|
|
mBrotliState = BrotliDecoderCreateInstance(nullptr, nullptr, nullptr);
|
Bug 1355661 - Add support for brotli streams in Jar archives. r=aklotz
Modern compression algorithms are better than zlib both in terms of
space and time. The jar format, used for e.g. omni.ja, addons, etc.
could benefit from using such modern algorithms, but the format only
allows a limited set of compression algorithms.
However, the format in itself is flexible, in that it can be extended
with arbitrary compression algorithms. This breaks compatibility with
programs like unzip, obviously, but we've never promised the files
shipped with Firefox will always remain "valid" zips (which they already
aren't, but they currently work with most zip readers).
With this change, we allow those archives to contain brotli streams,
using an arbitrary large value for the compression type in the Zip local
file header. This only allows to read such archives, but not to produce
them, and, for now, support for brotli streams is kept Nightly-only,
until everything is pieced together and we're happy to ship it.
--HG--
extra : rebase_source : fa637251f460ad0d91d5f5bec392c6e59555e80d
2017-04-07 08:48:25 +03:00
|
|
|
mMode = MODE_BROTLI;
|
|
|
|
mInCrc = item->CRC32();
|
|
|
|
mOutCrc = crc32(0L, Z_NULL, 0);
|
|
|
|
break;
|
|
|
|
#endif
|
|
|
|
|
2006-05-02 23:33:09 +04:00
|
|
|
default:
|
|
|
|
return NS_ERROR_NOT_IMPLEMENTED;
|
|
|
|
}
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2009-10-04 21:20:45 +04:00
|
|
|
// Must keep handle to filepointer and mmap structure as long as we need
|
|
|
|
// access to the mmapped data
|
2010-09-10 01:01:00 +04:00
|
|
|
mFd = aJar->mZip->GetFD();
|
|
|
|
mZs.next_in = (Bytef *)aJar->mZip->GetData(item);
|
2015-11-16 11:18:45 +03:00
|
|
|
if (!mZs.next_in) {
|
2009-12-31 21:10:20 +03:00
|
|
|
return NS_ERROR_FILE_CORRUPTED;
|
2015-11-16 11:18:45 +03:00
|
|
|
}
|
2009-10-17 19:54:54 +04:00
|
|
|
mZs.avail_in = item->Size();
|
|
|
|
mOutSize = item->RealSize();
|
2009-10-04 21:20:45 +04:00
|
|
|
mZs.total_out = 0;
|
2006-10-10 17:24:57 +04:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2009-08-13 00:50:12 +04:00
|
|
|
nsresult nsJARInputStream::InitDirectory(nsJAR *aJar,
|
2006-10-10 17:24:57 +04:00
|
|
|
const nsACString &aJarDirSpec,
|
|
|
|
const char *aDir) {
|
2015-02-10 01:34:50 +03:00
|
|
|
MOZ_ASSERT(aJar, "Argument may not be null");
|
|
|
|
MOZ_ASSERT(aDir, "Argument may not be null");
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2006-10-10 17:24:57 +04:00
|
|
|
// Mark it as closed, in case something fails in initialisation
|
2009-10-04 21:20:45 +04:00
|
|
|
mMode = MODE_CLOSED;
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2006-10-10 17:24:57 +04:00
|
|
|
// Keep the zipReader for getting the actual zipItems
|
2009-08-13 00:50:12 +04:00
|
|
|
mJar = aJar;
|
2006-10-10 17:24:57 +04:00
|
|
|
nsZipFind *find;
|
|
|
|
nsresult rv;
|
2007-01-22 04:47:50 +03:00
|
|
|
// We can get aDir's contents as strings via FindEntries
|
|
|
|
// with the following pattern (see nsIZipReader.findEntries docs)
|
|
|
|
// assuming dirName is properly escaped:
|
|
|
|
//
|
|
|
|
// dirName + "?*~" + dirName + "?*/?*"
|
|
|
|
nsDependentCString dirName(aDir);
|
|
|
|
mNameLen = dirName.Length();
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2007-01-22 04:47:50 +03:00
|
|
|
// iterate through dirName and copy it to escDirName, escaping chars
|
|
|
|
// which are special at the "top" level of the regexp so FindEntries
|
|
|
|
// works correctly
|
2012-09-02 06:35:17 +04:00
|
|
|
nsAutoCString escDirName;
|
2007-01-22 04:47:50 +03:00
|
|
|
const char *curr = dirName.BeginReading();
|
|
|
|
const char *end = dirName.EndReading();
|
|
|
|
while (curr != end) {
|
2009-10-04 21:20:45 +04:00
|
|
|
switch (*curr) {
|
2007-01-22 04:47:50 +03:00
|
|
|
case '*':
|
|
|
|
case '?':
|
|
|
|
case '$':
|
|
|
|
case '[':
|
|
|
|
case ']':
|
|
|
|
case '^':
|
|
|
|
case '~':
|
2018-11-30 13:46:48 +03:00
|
|
|
case '(':
|
|
|
|
case ')':
|
|
|
|
case '\\':
|
2007-01-22 04:47:50 +03:00
|
|
|
escDirName.Append('\\');
|
2006-10-10 17:24:57 +04:00
|
|
|
MOZ_FALLTHROUGH;
|
2009-10-17 19:54:54 +04:00
|
|
|
default:
|
|
|
|
escDirName.Append(*curr);
|
2006-10-10 17:24:57 +04:00
|
|
|
}
|
2018-11-30 13:46:48 +03:00
|
|
|
++curr;
|
|
|
|
}
|
2012-09-02 06:35:17 +04:00
|
|
|
nsAutoCString pattern = escDirName + NS_LITERAL_CSTRING("?*~") + escDirName +
|
2007-01-22 04:47:50 +03:00
|
|
|
NS_LITERAL_CSTRING("?*/?*");
|
2010-09-10 01:01:00 +04:00
|
|
|
rv = mJar->mZip->FindInit(pattern.get(), &find);
|
2006-10-10 17:24:57 +04:00
|
|
|
if (NS_FAILED(rv)) return rv;
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2006-10-10 17:24:57 +04:00
|
|
|
const char *name;
|
2012-08-22 19:56:38 +04:00
|
|
|
uint16_t nameLen;
|
2009-10-17 19:54:54 +04:00
|
|
|
while ((rv = find->FindNext(&name, &nameLen)) == NS_OK) {
|
|
|
|
// Must copy, to make it zero-terminated
|
|
|
|
mArray.AppendElement(nsCString(name, nameLen));
|
2018-11-30 13:46:48 +03:00
|
|
|
}
|
2006-10-10 17:24:57 +04:00
|
|
|
delete find;
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2006-10-10 17:24:57 +04:00
|
|
|
if (rv != NS_ERROR_FILE_TARGET_DOES_NOT_EXIST && NS_FAILED(rv)) {
|
|
|
|
return NS_ERROR_FAILURE; // no error translation
|
2018-11-30 13:46:48 +03:00
|
|
|
}
|
|
|
|
|
2006-10-10 17:24:57 +04:00
|
|
|
// Sort it
|
|
|
|
mArray.Sort();
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2006-10-10 17:24:57 +04:00
|
|
|
mBuffer.AssignLiteral("300: ");
|
|
|
|
mBuffer.Append(aJarDirSpec);
|
|
|
|
mBuffer.AppendLiteral(
|
|
|
|
"\n200: filename content-length last-modified file-type\n");
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2006-10-10 17:24:57 +04:00
|
|
|
// Open for reading
|
2009-10-04 21:20:45 +04:00
|
|
|
mMode = MODE_DIRECTORY;
|
|
|
|
mZs.total_out = 0;
|
2006-10-10 17:24:57 +04:00
|
|
|
mArrPos = 0;
|
2006-05-02 23:33:09 +04:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2017-07-06 15:00:35 +03:00
|
|
|
NS_IMETHODIMP
|
2012-08-22 19:56:38 +04:00
|
|
|
nsJARInputStream::Available(uint64_t *_retval) {
|
2009-10-04 21:20:45 +04:00
|
|
|
// A lot of callers don't check the error code.
|
|
|
|
// They just use the _retval value.
|
|
|
|
*_retval = 0;
|
|
|
|
|
|
|
|
switch (mMode) {
|
|
|
|
case MODE_NOTINITED:
|
|
|
|
break;
|
|
|
|
|
|
|
|
case MODE_CLOSED:
|
2006-01-02 05:30:32 +03:00
|
|
|
return NS_BASE_STREAM_CLOSED;
|
|
|
|
|
2009-10-04 21:20:45 +04:00
|
|
|
case MODE_DIRECTORY:
|
2006-10-10 17:24:57 +04:00
|
|
|
*_retval = mBuffer.Length();
|
2009-10-04 21:20:45 +04:00
|
|
|
break;
|
|
|
|
|
|
|
|
case MODE_INFLATE:
|
Bug 1355661 - Add support for brotli streams in Jar archives. r=aklotz
Modern compression algorithms are better than zlib both in terms of
space and time. The jar format, used for e.g. omni.ja, addons, etc.
could benefit from using such modern algorithms, but the format only
allows a limited set of compression algorithms.
However, the format in itself is flexible, in that it can be extended
with arbitrary compression algorithms. This breaks compatibility with
programs like unzip, obviously, but we've never promised the files
shipped with Firefox will always remain "valid" zips (which they already
aren't, but they currently work with most zip readers).
With this change, we allow those archives to contain brotli streams,
using an arbitrary large value for the compression type in the Zip local
file header. This only allows to read such archives, but not to produce
them, and, for now, support for brotli streams is kept Nightly-only,
until everything is pieced together and we're happy to ship it.
--HG--
extra : rebase_source : fa637251f460ad0d91d5f5bec392c6e59555e80d
2017-04-07 08:48:25 +03:00
|
|
|
#ifdef MOZ_JAR_BROTLI
|
|
|
|
case MODE_BROTLI:
|
|
|
|
#endif
|
2009-10-04 21:20:45 +04:00
|
|
|
case MODE_COPY:
|
|
|
|
*_retval = mOutSize - mZs.total_out;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2003-03-14 21:59:51 +03:00
|
|
|
return NS_OK;
|
1999-10-26 23:43:26 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2012-08-22 19:56:38 +04:00
|
|
|
nsJARInputStream::Read(char *aBuffer, uint32_t aCount, uint32_t *aBytesRead) {
|
2006-05-02 23:33:09 +04:00
|
|
|
NS_ENSURE_ARG_POINTER(aBuffer);
|
|
|
|
NS_ENSURE_ARG_POINTER(aBytesRead);
|
|
|
|
|
|
|
|
*aBytesRead = 0;
|
|
|
|
|
2009-09-03 16:15:19 +04:00
|
|
|
nsresult rv = NS_OK;
|
2010-11-11 23:13:48 +03:00
|
|
|
MOZ_WIN_MEM_TRY_BEGIN
|
2009-10-04 21:20:45 +04:00
|
|
|
switch (mMode) {
|
|
|
|
case MODE_NOTINITED:
|
|
|
|
return NS_OK;
|
|
|
|
|
|
|
|
case MODE_CLOSED:
|
|
|
|
return NS_BASE_STREAM_CLOSED;
|
|
|
|
|
|
|
|
case MODE_DIRECTORY:
|
|
|
|
return ReadDirectory(aBuffer, aCount, aBytesRead);
|
|
|
|
|
|
|
|
case MODE_INFLATE:
|
Bug 1355661 - Add support for brotli streams in Jar archives. r=aklotz
Modern compression algorithms are better than zlib both in terms of
space and time. The jar format, used for e.g. omni.ja, addons, etc.
could benefit from using such modern algorithms, but the format only
allows a limited set of compression algorithms.
However, the format in itself is flexible, in that it can be extended
with arbitrary compression algorithms. This breaks compatibility with
programs like unzip, obviously, but we've never promised the files
shipped with Firefox will always remain "valid" zips (which they already
aren't, but they currently work with most zip readers).
With this change, we allow those archives to contain brotli streams,
using an arbitrary large value for the compression type in the Zip local
file header. This only allows to read such archives, but not to produce
them, and, for now, support for brotli streams is kept Nightly-only,
until everything is pieced together and we're happy to ship it.
--HG--
extra : rebase_source : fa637251f460ad0d91d5f5bec392c6e59555e80d
2017-04-07 08:48:25 +03:00
|
|
|
#ifdef MOZ_JAR_BROTLI
|
|
|
|
case MODE_BROTLI:
|
|
|
|
#endif
|
2017-04-07 08:05:23 +03:00
|
|
|
if (mZs.total_out < mOutSize) {
|
2009-10-04 21:20:45 +04:00
|
|
|
rv = ContinueInflate(aBuffer, aCount, aBytesRead);
|
2018-11-30 13:46:48 +03:00
|
|
|
}
|
2009-10-04 21:20:45 +04:00
|
|
|
// be aggressive about releasing the file!
|
|
|
|
// note that sometimes, we will release mFd before we've finished
|
2006-10-10 17:24:57 +04:00
|
|
|
// deflating - this is because zlib buffers the input
|
2009-10-04 21:20:45 +04:00
|
|
|
if (mZs.avail_in == 0) {
|
2012-07-30 18:20:58 +04:00
|
|
|
mFd = nullptr;
|
2018-11-30 13:46:48 +03:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2009-10-04 21:20:45 +04:00
|
|
|
case MODE_COPY:
|
|
|
|
if (mFd) {
|
2013-01-15 16:22:03 +04:00
|
|
|
uint32_t count = std::min(aCount, mOutSize - uint32_t(mZs.total_out));
|
2009-10-04 21:20:45 +04:00
|
|
|
if (count) {
|
|
|
|
memcpy(aBuffer, mZs.next_in + mZs.total_out, count);
|
|
|
|
mZs.total_out += count;
|
2009-09-03 16:15:19 +04:00
|
|
|
}
|
2009-10-04 21:20:45 +04:00
|
|
|
*aBytesRead = count;
|
2018-11-30 13:46:48 +03:00
|
|
|
}
|
2009-10-04 21:20:45 +04:00
|
|
|
// be aggressive about releasing the file!
|
|
|
|
// note that sometimes, we will release mFd before we've finished copying.
|
|
|
|
if (mZs.total_out >= mOutSize) {
|
2012-07-30 18:20:58 +04:00
|
|
|
mFd = nullptr;
|
2009-10-04 21:20:45 +04:00
|
|
|
}
|
|
|
|
break;
|
2006-05-02 23:33:09 +04:00
|
|
|
}
|
2010-11-11 23:13:48 +03:00
|
|
|
MOZ_WIN_MEM_TRY_CATCH(rv = NS_ERROR_FAILURE)
|
2009-09-03 16:15:19 +04:00
|
|
|
return rv;
|
1999-10-26 23:43:26 +04:00
|
|
|
}
|
|
|
|
|
2000-08-22 11:03:33 +04:00
|
|
|
NS_IMETHODIMP
|
2012-08-22 19:56:38 +04:00
|
|
|
nsJARInputStream::ReadSegments(nsWriteSegmentFun writer, void *closure,
|
|
|
|
uint32_t count, uint32_t *_retval) {
|
2003-03-14 21:59:51 +03:00
|
|
|
// don't have a buffer to read from, so this better not be called!
|
|
|
|
return NS_ERROR_NOT_IMPLEMENTED;
|
2000-08-22 11:03:33 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2011-09-29 10:19:26 +04:00
|
|
|
nsJARInputStream::IsNonBlocking(bool *aNonBlocking) {
|
2011-10-17 18:59:28 +04:00
|
|
|
*aNonBlocking = false;
|
2002-03-12 03:59:06 +03:00
|
|
|
return NS_OK;
|
2000-08-22 11:03:33 +04:00
|
|
|
}
|
|
|
|
|
1999-10-26 23:43:26 +04:00
|
|
|
NS_IMETHODIMP
|
|
|
|
nsJARInputStream::Close() {
|
2012-04-12 01:55:22 +04:00
|
|
|
if (mMode == MODE_INFLATE) {
|
|
|
|
inflateEnd(&mZs);
|
|
|
|
}
|
Bug 1355661 - Add support for brotli streams in Jar archives. r=aklotz
Modern compression algorithms are better than zlib both in terms of
space and time. The jar format, used for e.g. omni.ja, addons, etc.
could benefit from using such modern algorithms, but the format only
allows a limited set of compression algorithms.
However, the format in itself is flexible, in that it can be extended
with arbitrary compression algorithms. This breaks compatibility with
programs like unzip, obviously, but we've never promised the files
shipped with Firefox will always remain "valid" zips (which they already
aren't, but they currently work with most zip readers).
With this change, we allow those archives to contain brotli streams,
using an arbitrary large value for the compression type in the Zip local
file header. This only allows to read such archives, but not to produce
them, and, for now, support for brotli streams is kept Nightly-only,
until everything is pieced together and we're happy to ship it.
--HG--
extra : rebase_source : fa637251f460ad0d91d5f5bec392c6e59555e80d
2017-04-07 08:48:25 +03:00
|
|
|
#ifdef MOZ_JAR_BROTLI
|
|
|
|
if (mMode == MODE_BROTLI) {
|
2017-08-09 13:45:39 +03:00
|
|
|
BrotliDecoderDestroyInstance(mBrotliState);
|
Bug 1355661 - Add support for brotli streams in Jar archives. r=aklotz
Modern compression algorithms are better than zlib both in terms of
space and time. The jar format, used for e.g. omni.ja, addons, etc.
could benefit from using such modern algorithms, but the format only
allows a limited set of compression algorithms.
However, the format in itself is flexible, in that it can be extended
with arbitrary compression algorithms. This breaks compatibility with
programs like unzip, obviously, but we've never promised the files
shipped with Firefox will always remain "valid" zips (which they already
aren't, but they currently work with most zip readers).
With this change, we allow those archives to contain brotli streams,
using an arbitrary large value for the compression type in the Zip local
file header. This only allows to read such archives, but not to produce
them, and, for now, support for brotli streams is kept Nightly-only,
until everything is pieced together and we're happy to ship it.
--HG--
extra : rebase_source : fa637251f460ad0d91d5f5bec392c6e59555e80d
2017-04-07 08:48:25 +03:00
|
|
|
}
|
|
|
|
#endif
|
2009-10-04 21:20:45 +04:00
|
|
|
mMode = MODE_CLOSED;
|
2012-07-30 18:20:58 +04:00
|
|
|
mFd = nullptr;
|
2003-03-14 21:59:51 +03:00
|
|
|
return NS_OK;
|
1999-10-26 23:43:26 +04:00
|
|
|
}
|
|
|
|
|
2012-08-22 19:56:38 +04:00
|
|
|
nsresult nsJARInputStream::ContinueInflate(char *aBuffer, uint32_t aCount,
|
|
|
|
uint32_t *aBytesRead) {
|
Bug 1355661 - Add support for brotli streams in Jar archives. r=aklotz
Modern compression algorithms are better than zlib both in terms of
space and time. The jar format, used for e.g. omni.ja, addons, etc.
could benefit from using such modern algorithms, but the format only
allows a limited set of compression algorithms.
However, the format in itself is flexible, in that it can be extended
with arbitrary compression algorithms. This breaks compatibility with
programs like unzip, obviously, but we've never promised the files
shipped with Firefox will always remain "valid" zips (which they already
aren't, but they currently work with most zip readers).
With this change, we allow those archives to contain brotli streams,
using an arbitrary large value for the compression type in the Zip local
file header. This only allows to read such archives, but not to produce
them, and, for now, support for brotli streams is kept Nightly-only,
until everything is pieced together and we're happy to ship it.
--HG--
extra : rebase_source : fa637251f460ad0d91d5f5bec392c6e59555e80d
2017-04-07 08:48:25 +03:00
|
|
|
bool finished = false;
|
|
|
|
|
2006-05-02 23:33:09 +04:00
|
|
|
// No need to check the args, ::Read did that, but assert them at least
|
|
|
|
NS_ASSERTION(aBuffer, "aBuffer parameter must not be null");
|
|
|
|
NS_ASSERTION(aBytesRead, "aBytesRead parameter must not be null");
|
1999-10-26 23:43:26 +04:00
|
|
|
|
2006-05-02 23:33:09 +04:00
|
|
|
// Keep old total_out count
|
2012-08-22 19:56:38 +04:00
|
|
|
const uint32_t oldTotalOut = mZs.total_out;
|
2017-07-06 15:00:35 +03:00
|
|
|
|
2006-05-02 23:33:09 +04:00
|
|
|
// make sure we aren't reading too much
|
2013-01-15 16:22:03 +04:00
|
|
|
mZs.avail_out = std::min(aCount, (mOutSize - oldTotalOut));
|
2009-10-04 21:20:45 +04:00
|
|
|
mZs.next_out = (unsigned char *)aBuffer;
|
1999-10-26 23:43:26 +04:00
|
|
|
|
Bug 1355661 - Add support for brotli streams in Jar archives. r=aklotz
Modern compression algorithms are better than zlib both in terms of
space and time. The jar format, used for e.g. omni.ja, addons, etc.
could benefit from using such modern algorithms, but the format only
allows a limited set of compression algorithms.
However, the format in itself is flexible, in that it can be extended
with arbitrary compression algorithms. This breaks compatibility with
programs like unzip, obviously, but we've never promised the files
shipped with Firefox will always remain "valid" zips (which they already
aren't, but they currently work with most zip readers).
With this change, we allow those archives to contain brotli streams,
using an arbitrary large value for the compression type in the Zip local
file header. This only allows to read such archives, but not to produce
them, and, for now, support for brotli streams is kept Nightly-only,
until everything is pieced together and we're happy to ship it.
--HG--
extra : rebase_source : fa637251f460ad0d91d5f5bec392c6e59555e80d
2017-04-07 08:48:25 +03:00
|
|
|
#ifndef MOZ_JAR_BROTLI
|
|
|
|
MOZ_ASSERT(mMode == MODE_INFLATE);
|
|
|
|
#endif
|
|
|
|
if (mMode == MODE_INFLATE) {
|
|
|
|
// now inflate
|
|
|
|
int zerr = inflate(&mZs, Z_SYNC_FLUSH);
|
|
|
|
if ((zerr != Z_OK) && (zerr != Z_STREAM_END)) {
|
|
|
|
return NS_ERROR_FILE_CORRUPTED;
|
|
|
|
}
|
|
|
|
finished = (zerr == Z_STREAM_END);
|
|
|
|
#ifdef MOZ_JAR_BROTLI
|
|
|
|
} else {
|
|
|
|
MOZ_ASSERT(mMode == MODE_BROTLI);
|
|
|
|
/* The brotli library wants size_t, but z_stream only contains
|
|
|
|
* unsigned int for avail_* and unsigned long for total_*.
|
|
|
|
* So use temporary stack values. */
|
|
|
|
size_t avail_in = mZs.avail_in;
|
|
|
|
size_t avail_out = mZs.avail_out;
|
|
|
|
size_t total_out = mZs.total_out;
|
2017-08-09 13:45:39 +03:00
|
|
|
BrotliDecoderResult result = BrotliDecoderDecompressStream(
|
|
|
|
mBrotliState, &avail_in,
|
Bug 1355661 - Add support for brotli streams in Jar archives. r=aklotz
Modern compression algorithms are better than zlib both in terms of
space and time. The jar format, used for e.g. omni.ja, addons, etc.
could benefit from using such modern algorithms, but the format only
allows a limited set of compression algorithms.
However, the format in itself is flexible, in that it can be extended
with arbitrary compression algorithms. This breaks compatibility with
programs like unzip, obviously, but we've never promised the files
shipped with Firefox will always remain "valid" zips (which they already
aren't, but they currently work with most zip readers).
With this change, we allow those archives to contain brotli streams,
using an arbitrary large value for the compression type in the Zip local
file header. This only allows to read such archives, but not to produce
them, and, for now, support for brotli streams is kept Nightly-only,
until everything is pieced together and we're happy to ship it.
--HG--
extra : rebase_source : fa637251f460ad0d91d5f5bec392c6e59555e80d
2017-04-07 08:48:25 +03:00
|
|
|
const_cast<const unsigned char **>(&mZs.next_in), &avail_out,
|
2017-08-09 13:45:39 +03:00
|
|
|
&mZs.next_out, &total_out);
|
Bug 1355661 - Add support for brotli streams in Jar archives. r=aklotz
Modern compression algorithms are better than zlib both in terms of
space and time. The jar format, used for e.g. omni.ja, addons, etc.
could benefit from using such modern algorithms, but the format only
allows a limited set of compression algorithms.
However, the format in itself is flexible, in that it can be extended
with arbitrary compression algorithms. This breaks compatibility with
programs like unzip, obviously, but we've never promised the files
shipped with Firefox will always remain "valid" zips (which they already
aren't, but they currently work with most zip readers).
With this change, we allow those archives to contain brotli streams,
using an arbitrary large value for the compression type in the Zip local
file header. This only allows to read such archives, but not to produce
them, and, for now, support for brotli streams is kept Nightly-only,
until everything is pieced together and we're happy to ship it.
--HG--
extra : rebase_source : fa637251f460ad0d91d5f5bec392c6e59555e80d
2017-04-07 08:48:25 +03:00
|
|
|
/* We don't need to update avail_out, it's not used outside this
|
|
|
|
* function. */
|
|
|
|
mZs.total_out = total_out;
|
|
|
|
mZs.avail_in = avail_in;
|
2017-08-09 13:45:39 +03:00
|
|
|
if (result == BROTLI_DECODER_RESULT_ERROR) {
|
Bug 1355661 - Add support for brotli streams in Jar archives. r=aklotz
Modern compression algorithms are better than zlib both in terms of
space and time. The jar format, used for e.g. omni.ja, addons, etc.
could benefit from using such modern algorithms, but the format only
allows a limited set of compression algorithms.
However, the format in itself is flexible, in that it can be extended
with arbitrary compression algorithms. This breaks compatibility with
programs like unzip, obviously, but we've never promised the files
shipped with Firefox will always remain "valid" zips (which they already
aren't, but they currently work with most zip readers).
With this change, we allow those archives to contain brotli streams,
using an arbitrary large value for the compression type in the Zip local
file header. This only allows to read such archives, but not to produce
them, and, for now, support for brotli streams is kept Nightly-only,
until everything is pieced together and we're happy to ship it.
--HG--
extra : rebase_source : fa637251f460ad0d91d5f5bec392c6e59555e80d
2017-04-07 08:48:25 +03:00
|
|
|
return NS_ERROR_FILE_CORRUPTED;
|
2015-11-16 11:18:45 +03:00
|
|
|
}
|
2017-08-09 13:45:39 +03:00
|
|
|
finished = (result == BROTLI_DECODER_RESULT_SUCCESS);
|
2018-11-30 13:46:48 +03:00
|
|
|
#endif
|
|
|
|
}
|
1999-10-26 23:43:26 +04:00
|
|
|
|
2009-10-04 21:20:45 +04:00
|
|
|
*aBytesRead = (mZs.total_out - oldTotalOut);
|
2006-05-02 23:33:09 +04:00
|
|
|
|
|
|
|
// Calculate the CRC on the output
|
2009-10-04 21:20:45 +04:00
|
|
|
mOutCrc = crc32(mOutCrc, (unsigned char *)aBuffer, *aBytesRead);
|
2006-05-02 23:33:09 +04:00
|
|
|
|
|
|
|
// be aggressive about ending the inflation
|
|
|
|
// for some reason we don't always get Z_STREAM_END
|
Bug 1355661 - Add support for brotli streams in Jar archives. r=aklotz
Modern compression algorithms are better than zlib both in terms of
space and time. The jar format, used for e.g. omni.ja, addons, etc.
could benefit from using such modern algorithms, but the format only
allows a limited set of compression algorithms.
However, the format in itself is flexible, in that it can be extended
with arbitrary compression algorithms. This breaks compatibility with
programs like unzip, obviously, but we've never promised the files
shipped with Firefox will always remain "valid" zips (which they already
aren't, but they currently work with most zip readers).
With this change, we allow those archives to contain brotli streams,
using an arbitrary large value for the compression type in the Zip local
file header. This only allows to read such archives, but not to produce
them, and, for now, support for brotli streams is kept Nightly-only,
until everything is pieced together and we're happy to ship it.
--HG--
extra : rebase_source : fa637251f460ad0d91d5f5bec392c6e59555e80d
2017-04-07 08:48:25 +03:00
|
|
|
if (finished || mZs.total_out == mOutSize) {
|
|
|
|
if (mMode == MODE_INFLATE) {
|
|
|
|
inflateEnd(&mZs);
|
|
|
|
}
|
2006-05-02 23:33:09 +04:00
|
|
|
|
|
|
|
// stop returning valid data as soon as we know we have a bad CRC
|
2015-11-16 11:18:45 +03:00
|
|
|
if (mOutCrc != mInCrc) {
|
2006-05-02 23:33:09 +04:00
|
|
|
return NS_ERROR_FILE_CORRUPTED;
|
|
|
|
}
|
2018-11-30 13:46:48 +03:00
|
|
|
}
|
2006-05-02 23:33:09 +04:00
|
|
|
|
|
|
|
return NS_OK;
|
1999-10-26 23:43:26 +04:00
|
|
|
}
|
2006-10-10 17:24:57 +04:00
|
|
|
|
2012-08-22 19:56:38 +04:00
|
|
|
nsresult nsJARInputStream::ReadDirectory(char *aBuffer, uint32_t aCount,
|
|
|
|
uint32_t *aBytesRead) {
|
2006-10-10 17:24:57 +04:00
|
|
|
// No need to check the args, ::Read did that, but assert them at least
|
|
|
|
NS_ASSERTION(aBuffer, "aBuffer parameter must not be null");
|
|
|
|
NS_ASSERTION(aBytesRead, "aBytesRead parameter must not be null");
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2006-10-10 17:24:57 +04:00
|
|
|
// If the buffer contains data, copy what's there up to the desired amount
|
2012-08-22 19:56:38 +04:00
|
|
|
uint32_t numRead = CopyDataToBuffer(aBuffer, aCount);
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2006-10-10 17:24:57 +04:00
|
|
|
if (aCount > 0) {
|
|
|
|
// empty the buffer and start writing directory entry lines to it
|
|
|
|
mBuffer.Truncate();
|
|
|
|
mCurPos = 0;
|
2012-08-22 19:56:38 +04:00
|
|
|
const uint32_t arrayLen = mArray.Length();
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2006-10-10 17:24:57 +04:00
|
|
|
for (; aCount > mBuffer.Length(); mArrPos++) {
|
|
|
|
// have we consumed all the directory contents?
|
|
|
|
if (arrayLen <= mArrPos) break;
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2009-01-22 07:15:34 +03:00
|
|
|
const char *entryName = mArray[mArrPos].get();
|
2012-08-22 19:56:38 +04:00
|
|
|
uint32_t entryNameLen = mArray[mArrPos].Length();
|
2010-09-10 01:01:00 +04:00
|
|
|
nsZipItem *ze = mJar->mZip->GetItem(entryName);
|
2006-10-10 17:24:57 +04:00
|
|
|
NS_ENSURE_TRUE(ze, NS_ERROR_FILE_TARGET_DOES_NOT_EXIST);
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2006-10-10 17:24:57 +04:00
|
|
|
// Last Modified Time
|
|
|
|
PRExplodedTime tm;
|
2009-12-16 02:01:08 +03:00
|
|
|
PR_ExplodeTime(ze->LastModTime(), PR_GMTParameters, &tm);
|
2006-10-10 17:24:57 +04:00
|
|
|
char itemLastModTime[65];
|
|
|
|
PR_FormatTimeUSEnglish(itemLastModTime, sizeof(itemLastModTime),
|
|
|
|
" %a,%%20%d%%20%b%%20%Y%%20%H:%M:%S%%20GMT ", &tm);
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2006-10-10 17:24:57 +04:00
|
|
|
// write a 201: line to the buffer for this item
|
|
|
|
// 200: filename content-length last-modified file-type
|
|
|
|
mBuffer.AppendLiteral("201: ");
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2006-10-10 17:24:57 +04:00
|
|
|
// Names must be escaped and relative, so use the pre-calculated length
|
|
|
|
// of the directory name as the offset into the string
|
|
|
|
// NS_EscapeURL adds the escaped URL to the give string buffer
|
|
|
|
NS_EscapeURL(entryName + mNameLen, entryNameLen - mNameLen,
|
|
|
|
esc_Minimal | esc_AlwaysCopy, mBuffer);
|
2018-11-30 13:46:48 +03:00
|
|
|
|
2006-10-10 17:24:57 +04:00
|
|
|
mBuffer.Append(' ');
|
2009-10-17 19:54:54 +04:00
|
|
|
mBuffer.AppendInt(ze->RealSize(), 10);
|
2006-10-10 17:24:57 +04:00
|
|
|
mBuffer.Append(itemLastModTime); // starts/ends with ' '
|
2017-07-06 15:00:35 +03:00
|
|
|
if (ze->IsDirectory())
|
2006-10-10 17:24:57 +04:00
|
|
|
mBuffer.AppendLiteral("DIRECTORY\n");
|
|
|
|
else
|
|
|
|
mBuffer.AppendLiteral("FILE\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
// Copy up to the desired amount of data to buffer
|
|
|
|
numRead += CopyDataToBuffer(aBuffer, aCount);
|
2018-11-30 13:46:48 +03:00
|
|
|
}
|
|
|
|
|
2006-10-10 17:24:57 +04:00
|
|
|
*aBytesRead = numRead;
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2012-08-22 19:56:38 +04:00
|
|
|
uint32_t nsJARInputStream::CopyDataToBuffer(char *&aBuffer, uint32_t &aCount) {
|
2013-01-15 16:22:03 +04:00
|
|
|
const uint32_t writeLength = std::min(aCount, mBuffer.Length() - mCurPos);
|
2006-10-10 17:24:57 +04:00
|
|
|
|
|
|
|
if (writeLength > 0) {
|
|
|
|
memcpy(aBuffer, mBuffer.get() + mCurPos, writeLength);
|
|
|
|
mCurPos += writeLength;
|
|
|
|
aCount -= writeLength;
|
|
|
|
aBuffer += writeLength;
|
|
|
|
}
|
|
|
|
|
|
|
|
// return number of bytes copied to the buffer so the
|
|
|
|
// Read method can return the number of bytes copied
|
|
|
|
return writeLength;
|
|
|
|
}
|