RFR JDK-6372077: Manifest should handle manifest attribute names up to 70 bytes
philipp.kunz at paratix.ch
Fri Dec 8 22:43:13 UTC 2017
After I haven't found a sponsor so far, I try to make it even easier
this time by providing a hopefully ready patch this time. See
http://files.paratix.ch/jdk/6372077/webrev.01/ or the attached
In short, this patch increases the manifest files line width by two
bytes in order to provide enough space for up to 70 bytes of a header
name and the following two bytes of the ": " delimiter in order to
fulfill the manifest specification that does not allow header names and
the delimiter to be broken across lines in
Manifest#make72Safe(StringBuffer). It also changes that make72Safe is
now not anymore invoked with the trailing line break in the StringBuffer
argument but appended only after that call which makes make72Safe
simpler by one if and one subtraction and affects three places where it
While the bug says in its title it relates to JarFile.getManifest() it
is actually caused in class Manifest. Therefore I added a test about
exactly what the bug says in Bug6372077jarFileManifestAttr70 along with
another test LineBreakLineWidth that covers the actual fix.
All my other considerations and reasoning are already written down in
either the preceding mails included below or as comments in the patch.
I'd be glad to get any kind of feedback and am looking forward to
closing another bug.
On 21.11.2017 07:18, Philipp Kunz wrote:
> Hi everyone,
> I haven't got any reply now for around three weeks and now i start to
> wonder if I just missed it or if I should refine my approach to find a
> sponsor or if it helped if I presented a ready patch or if noone
> considers this important enough or anything else whatever. This is
> only my second contribution hence I don't know the procedure well.
> One point maybe worth to point out again is that I don't want to
> support manifest headers longer than 70 character, just up to 70,
> which has always been the intention but has only worked up to 68. This
> might have been written confusingly in my last email.
> As far as I understood, I should first get a sponsor. In any case, is
> there any suggestion for how to proceed?
> On 03.11.2017 00:04, Philipp Kunz wrote:
>> Hi Sean and Max and all others,
>> Thank you Sean for the hint about the right mailing list. And thanks
>> also for his hint to Max to make smaller portions of changes.
>> I would like to contribute a fix for JDK-6372077 which is about
>> JarFile.getManifest() should handle manifest attribute name[s longer
>> than] 70 bytes.
>> It looks like the bug is caused by Manifest.make72Safe breaking lines
>> at 70 bytes instead of 72 despite its comment and name
>> resulting StringBuffer has then lines of 72 bytes maximum each
>> including the following line break. Without the line break that
>> leaves 70 bytes of characters per line. On the other hand, header
>> names can be up to 70 bytes (only single-byte utf-8 characters) and
>> cannot be broken across a line break and need to be followed by a
>> colon and a space which must be on the same line too according to the
>> specification. When breaking at 70 bytes excluding the line break,
>> however, long header names don't fit in one line together with the
>> colon space delimiter because there is not sufficient space.
>> Manifests with names up to 70 bytes long can still be written without
>> immediate exception but the resulting manifests are illegal in my
>> opinion. When later reading such manifests
>> an error occurs as a consequence of the bad manifest. This is more or
>> less the current situation and also what JDK-6372077 already knew.
>> --> After all, in order to fix it, i'd like to propose to make
>> manifest file lines wider by two bytes.
>> The only proper alternative that came into my mind would be to change
>> the manifest specification and reduce the maximum header name length
>> there by two and also in the code. If that would break any existing
>> code i guess that would affect code only that produced invalid
>> manifests and would be acceptable.
>> Supporting all existing and possibly invalid manifests would mean to
>> add support for reading headers the delimiters of which are broken
>> onto the next line which I consider too complex with respect to the
>> value added and even more so considering that those invalid manifest
>> can be assumed to have been detected as such by reading them and also
>> because it would be a feature that would be used less and less over
>> time if the code to write manifest is changed at the same time to
>> produce only valid manifests in the discussed respect here. I don't
>> think this should be actually done.
>> Before I actually do the leg work, i'd like to ask, if there are
>> concerns or objections or tips for such a change or if anyone can or
>> cannot follow the reasoning and the conclusion to make manifests 2
>> bytes wider or if i missed an important point altogether.
>> In case there will be a consent about how to solve this, would
>> someone volunteer to sponsor? That may be less urgent at the moment
>> than the question above about how to proceed.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 18891 bytes
Desc: not available
More information about the core-libs-dev