JDK-4842483 : 72-byte line length limit when reading manifest files should be removed
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 1.4.0,1.4.1
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: generic,windows_2000
  • CPU: generic,x86
  • Submitted: 2003-04-03
  • Updated: 2010-11-18
Related Reports
Duplicate :  
JDK-4620323 - Manifest read() should remove 512 byte limit for Manifest main attributes
Relates :  
JDK-6372077 - JarFile.getManifest() should handle manifest attribute name 70 bytes
Relates :  
JDK-4245700 - Manifest spec and Class-Path header spec are contradictory
Relates :  
JDK-6443578 - Continuation lines in JAR manifests do not follow RFC-822
Description
Name: gm110360			Date: 04/03/2003


A DESCRIPTION OF THE REQUEST :
The Class-Path manifest file option has a length limit of 512 bytes for its value. Cannot specify complete list of Jars for our application. Cannot take advantage of Jar indexing feature because of this limitation.

JUSTIFICATION :
The 512 byte limitation is preventing our application from taking full advantage from the Jar indexing feature. We have over 60 Jars that need to be indexed to enhance the download process. There also seems to be no reason to even have such limitation.

EXPECTED VERSUS ACTUAL BEHAVIOR :
Jar utility to dynamically allocate space for any (at least 2K) size for the Class-Path manifest option value.
The "Line too long" Exception is thrown.

CUSTOMER SUBMITTED WORKAROUND :
No work around, except to rename our jar files with a short meanigless names
(Review ID: 183364) 
======================================================================
Comments
EVALUATION The RFC 822 spec (on which the Manifest spec is based) states: Each header field may be represented on exactly one line con- sisting of the name of the field and its body, and terminated by a CRLF; this is what the parser sees. For readability, the field-body portion of long header fields may be "folded" onto multiple lines of the actual field. "Long" is commonly inter- preted to mean greater than 65 or 72 characters. The former length serves as a limit, when the message is to be viewed on most simple terminals which use simple display software; how- ever, the limit is not imposed by this standard. So manifests should also have no line length limit.
09-05-2006
PUBLIC COMMENTS -
08-07-2004
WORK AROUND Manifest files containing lines longer than 72 bytes are malformed. If there is customer-owned code that generates such manifest files, it should be changed to generate continuation lines. If there is Sun-distributed code that generates such manifest files, the manifest file can be extracted, modified to use continuation lines, and the jar file repackaged with the fixed manifest. ###@###.### 2003-06-27 Use the Manifest.write method to generate manifest files instead of writing them "by hand". For example, this code: public static void main (String[] args) throws Exception { Manifest m = new Manifest(); Attributes a = m.getMainAttributes(); a.put(Attributes.Name.MANIFEST_VERSION, "3.14"); a.put(Attributes.Name.CLASS_PATH, "/some/very/long/paaaaaaaaaaaaaaaaaaaaaaaaaath1 " + "/some/very/long/paaaaaaaaaaaaaaaaaaaaaaaaaath2 " + "/some/very/long/paaaaaaaaaaaaaaaaaaaaaaaaaath3 " + "/some/very/long/paaaaaaaaaaaaaaaaaaaaaaaaaath4 " + "/some/very/long/paaaaaaaaaaaaaaaaaaaaaaaaaath5 " + "/some/very/long/paaaaaaaaaaaaaaaaaaaaaaaaaath6"); m.write(System.out); generates an output file with 72-byte lines and continuation lines. ###@###.### 2003-08-07
07-08-2003
EVALUATION The JAR File spec http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#JAR%20Manifest states: ------------------------------------------------------------------------ * Line length: No line may be longer than 72 bytes (not characters), in its UTF8-encoded form. If a value would make the initial line longer than this, it should be continued on extra lines (each starting with a single SPACE). -------------------------------------------------------------------------- So any program that writes manifest files should ensure that long lines (longer than 72, not 512 UTF8 bytes, that is) should be written using continuations. That said, there is no reason why code that reads manifest files, as in Manifest.java, cannot simply accept input lines of ANY length. The 72-byte restriction is a restriction inherited from RFC 822, but that is a network communication protocol designed for maximal legacy portability for the 70s, which should not be an issue any more. We should remove all length restrictions when reading. We should also audit all J2SE code that writes manifest files to ensure that the 72-byte limit is observed. Be lenient in what you accept, standards-compliant in what you generate. ###@###.### 2003-06-27 The Jar File Specification makes it clear that lines in the Manifest file must be a maximum of 72 bytes long, with provision for line continuation. Java APIs like Manifest.write correctly generate such line continuations. Keeping this in mind, there is no reason why the implementation need accept any input lines longer than 72 bytes. The fact that it accepts even 512 bytes is generous. There is no bug in the current implementation. However, the specification is poor. This kind of restriction (RFC822) was intended as an interchange file format for ancient computer systems. Today we should design all file formats to never have such arbitrary length restrictions. Because the jar file format is an interchange format between different Java implementations, the old format must be supported for years, if not decades. The default must remain to generate Manifest files with the 72byte limit, and the limit must continue to be documented, so that tools that generate Manifests programmatically can continue to generate portable jar files. Nevertheless, the spec should be changed so that all future implementations have no line length limit. Perhaps 20 years after this is implemented, we can abandon compatibility with old Java implemenations and by default generate new jar files with long lines. ###@###.### 2003-08-07
07-08-2003