You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by bu...@apache.org on 2011/01/06 12:10:56 UTC
DO NOT REPLY [Bug 50548] New: Log4j v1.2 download page serving HTML
files rather than archives
https://issues.apache.org/bugzilla/show_bug.cgi?id=50548
Summary: Log4j v1.2 download page serving HTML files rather
than archives
Product: Log4j
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Other
AssignedTo: log4j-dev@logging.apache.org
ReportedBy: dominic.dunlop@uni.lu
Created an attachment (id=26462)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=26462)
Archive of terminal session and incorrectly downloaded file
The supplied signatures and md5 checksums match neither the tar nor the zip
archives on http://logging.apache.org/log4j/1.2/download.html, the download
page for log4j 1.2. The reason is that the files are not archives, but HTML
source. The attached archive contains a log of a terminal session on a virtual
server running 64-bit Ubuntu 10.04 that illustrates the issue.
If one loads the HTML in a browser, one is presented with a list of mirrors
from which one can correctly download the archive. The behaviour is not
peculiar to wget: I have verified using Safari on Mac OS X and using wget on
another Macintosh connected to the Internet via a different ISP. The second
file in the attached archive is the .tar.gz "archive" downlaoded by Safari,
which is in fact gzip-compressed HTML. (The same file arrived uncompressed when
I used wget.)
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
DO NOT REPLY [Bug 50548] Log4j v1.2 download page serving HTML files
rather than archives
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50548
Curt Arnold <ca...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
--- Comment #1 from Curt Arnold <ca...@apache.org> 2011-01-09 01:16:28 EST ---
The behavior is by design and the issue with Safari is an reported and
acknowledged "feature" in Safari. The following statement appears at the top
of the downloads page:
The link in the Mirrors column should display a list of available mirrors with
a default selection based on your inferred location. If you do not see that
page, try a different browser. The checksum and signature are links to the
originals on the main distribution server.
The page is a list of mirrors and is displayed correctly by browsers that honor
the content type in the HTTP response. Unfortunately Safari decides to ignore
the explicit instructions from the web server and guess at the content type
based on the extension. That has been logged as a WebKit bug several years
back, but is unlikely to change. It is likely a generally beneficial deviation
from the HTTP recommendation for Safari since it is generally more likely that
the web server is wrong on the content type and the extension is correct, but
the spec says that an explicit content type from the HTTP server should be
assumed to be correct.
As for wget or curl, the problem is the assumption that the link would provide
an archive. The page where you got the link, explicitly said that you would
not get the archive.
It is less than ideal, but working around Safari's deviation from the spec
hasn't seen to be the best use of our time.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org