RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields [v3]
Lin Zang
lzang at openjdk.java.net
Fri Mar 26 02:40:28 UTC 2021
On Mon, 22 Mar 2021 20:06:33 GMT, Lance Andersen <lancea at openjdk.org> wrote:
>> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - update copyright
>> - reuse arguments constructor for non-argument one.
>
> src/java.base/share/classes/java/util/zip/GZIPOutputStream.java line 320:
>
>> 318: * +---+---+=================================+
>> 319: */
>> 320: int xlen = extraFieldBytes.length;
>
> On a quick look at the RFC, I noticed the following:
>
> ------------------------
> 2.3.1.1. Extra field
>
> If the FLG.FEXTRA bit is set, an "extra field" is present in
> the header, with total length XLEN bytes. It consists of a
> series of subfields, each of the form:
>
> +---+---+---+---+==================================+
> |SI1|SI2| LEN |... LEN bytes of subfield data ...|
> +---+---+---+---+==================================+
>
> SI1 and SI2 provide a subfield ID, typically two ASCII letters
> with some mnemonic value. Jean-Loup Gailly
> <gzip at prep.ai.mit.edu> is maintaining a registry of subfield
> IDs; please send him any subfield ID you wish to use. Subfield
> IDs with SI2 = 0 are reserved for future use. The following
> IDs are currently defined:
>
>
> ---------------
>
> This does not seem to be accounted for or is it?
Yes, This should be considered, I will add logic in the code.
However, I did some search and found that there is only one subfield defined, which is mentioned in RFC:
SI1 SI2 Data
---------- ---------- ----
0x41 ('A') 0x70 ('P') Apollo file type information
or SI2 = 0 is reserved.
It seems this subfield definition is no longe maintained. (FYI, https://stackoverflow.com/questions/65188890/what-gzip-extra-field-subfields-exist)
So is it ok if make it only accept these two cases for FLG.FEXTRA and reject others?
-------------
PR: https://git.openjdk.java.net/jdk/pull/3072
More information about the core-libs-dev
mailing list