Permament move (error 301) not handled properly by Lightweight HTTP Wagon

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.0-beta-6
  • Fix Version/s: 2.0
  • Component/s: wagon-http-lightweight
  • Labels:
    None
  • Patch Submitted:
    Yes

Description

Artifact cannot be downloaded by http-lightweight-wagon used (as default) in all Maven versions except 2.2.0, which uses http-wagon by default.
Instead of pom and jar files html files appear in the local repo with content like:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://download.java.net/maven/2/org/codehaus/castor/castor-xml-schema/1.2/castor-xml-schema-1.2.pom">here</a>.</p>
<hr>
<address>Apache Server at maven2-repository.dev.java.net Port 443</address>
</body></html>

Only Maven 2.2.0 handles 301 properly.

By the way, I haven't expected such Apache configuration (permament move) in central Maven repo.
As you can see this is not handled properly by almost all versions of Maven.

Issue Links

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. MNG-4838 Permament move (error 301) not handled properly by Maven

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Open - The issue is open and ready for the assignee to start work on it.
is duplicated by

Bug - A problem which impairs or prevents the functions of the product. MNG-4524 Error while installing dependencies

  • Blocker - Blocks development and/or testing work, production could not run
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-4486 Maven appears to ignore http 301; downloads html as jar

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-4734 Maven pom resolving does not respect a 301 permanent redirect

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-4816 Maven 3 fails to follow 301 redirects

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-4817 Unable to use gwt-maven-plugin 1.3-SNAPSHOT

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MREPOSITORY-20 301 permanently moved (not following redirect)

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is related to

Task - A task that needs to be done. CARGO-840 Cargo 1.0.2 (possibly also earlier releases) don't work with Maven since the migration to the new Codehaus repo

  • Blocker - Blocks development and/or testing work, production could not run
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Sub-task - The sub-task of the issue MNG-4448 Create IT to check for support of HTTP redirects

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MANTTASKS-176 Maven Ant Tasks doesn't follow HTTP redirects

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Bug - A problem which impairs or prevents the functions of the product. WAGON-283 Maven 2.2.0 fails to follow redirects when deploying artifacts via HTTP

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Open - The issue is open and ready for the assignee to start work on it.

Bug - A problem which impairs or prevents the functions of the product. MEV-649 log4j 1.2.15 points to nonfuctional maven-repository.dev.java.net packages breaking whole build

  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MARCHETYPES-36 Version 1.1. of the web and EE archetypes broken

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. WAGON-284 Artifacts are uploaded twice in the case of HTTP redirection

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Benjamin Bentmann added a comment -

By the way, I haven't expected such Apache configuration (permament move) in central Maven repo.

As a side note, the central Maven repository is repo1.maven.org, not "Apache Server at maven2-repository.dev.java.net Port 443".

Show
Benjamin Bentmann added a comment -
By the way, I haven't expected such Apache configuration (permament move) in central Maven repo.
As a side note, the central Maven repository is repo1.maven.org, not "Apache Server at maven2-repository.dev.java.net Port 443".
Hide
Permalink
Paul Loy added a comment -

I would suggest that this is a little more important than minor. I'm having to add about 10 repos to my pom in order to work around this issue with redirects and the default maven repo.

Show
Paul Loy added a comment - I would suggest that this is a little more important than minor. I'm having to add about 10 repos to my pom in order to work around this issue with redirects and the default maven repo.
Hide
Permalink
Steve Kuo added a comment - - edited

This should be major priority. Basically if any repository returns HTTP 301 Moved, then Maven blindly copies the moved HTML as a JAR (an obvious bug). The result is that the build is broken. I've had to edit my settings.xml and create a local repository with manually downloaded JARs - a major pain. See also http://jira.codehaus.org/browse/MEV-649

Show
Steve Kuo added a comment - - edited This should be major priority. Basically if any repository returns HTTP 301 Moved, then Maven blindly copies the moved HTML as a JAR (an obvious bug). The result is that the build is broken. I've had to edit my settings.xml and create a local repository with manually downloaded JARs - a major pain. See also http://jira.codehaus.org/browse/MEV-649
Hide
Permalink
Benjamin Jaton added a comment -

Definitively a major issue since log4j 1.2.15 is impacted ( MEV-649 )
This bugs seems to be around since a long time though : MAVEN-1831 ( 31/Jan/07 ), I don't know why such a blocking issue hasn't been fixed already.

Show
Benjamin Jaton added a comment - Definitively a major issue since log4j 1.2.15 is impacted ( MEV-649 ) This bugs seems to be around since a long time though : MAVEN-1831 ( 31/Jan/07 ), I don't know why such a blocking issue hasn't been fixed already.
Hide
Permalink
Kyle W. Cartmell added a comment -

+1 to fix ASAP - this is a huge problem as it breaks log4j 1.2.15 as Benjamin has previously stated.

Show
Kyle W. Cartmell added a comment - +1 to fix ASAP - this is a huge problem as it breaks log4j 1.2.15 as Benjamin has previously stated.
Hide
Permalink
Data Nucleus added a comment - - edited

+1. Recent changes in SUN's M2 repo has broken local repos for me for artifacts for JMX, JMXTOOLS, JMS, MAIL, as per one of the linked JIRAs (about log4j, saying it is log4j's POM fault, but then Maven shouldn't break the repo in the first place)

Show
Data Nucleus added a comment - - edited +1. Recent changes in SUN's M2 repo has broken local repos for me for artifacts for JMX, JMXTOOLS, JMS, MAIL, as per one of the linked JIRAs (about log4j, saying it is log4j's POM fault, but then Maven shouldn't break the repo in the first place)
Hide
Permalink
Stephen Compall added a comment -

The underlying cause seems to be wagon-http-lightweight's reliance on HttpURLConnection's redirect behavior. One should first note that all the problematic redirects in question are cross-protocol, i.e. https->http or vice versa.

Then, consider sun.net.www.protocol.http.HttpURLConnection.followRedirect, which always returns false (don't follow) when the protocol of the old URL doesn't match that of the new one. See line 1830 in openjdk-6-src-b18-16_feb_2010 for the specifics.

Many thanks to John Raymond Wold for figuring out why the HttpURLConnection wasn't redirecting.

Show
Stephen Compall added a comment - The underlying cause seems to be wagon-http-lightweight's reliance on HttpURLConnection's redirect behavior. One should first note that all the problematic redirects in question are cross-protocol, i.e. https->http or vice versa. Then, consider sun.net.www.protocol.http.HttpURLConnection.followRedirect, which always returns false (don't follow) when the protocol of the old URL doesn't match that of the new one. See line 1830 in openjdk-6-src-b18-16_feb_2010 for the specifics. Many thanks to John Raymond Wold for figuring out why the HttpURLConnection wasn't redirecting.
Hide
Permalink
Stephen Compall added a comment -

Patch to wagon-1.0-beta-2 to drive redirects not automatically handled; see my previous comment.

Show
Stephen Compall added a comment - Patch to wagon-1.0-beta-2 to drive redirects not automatically handled; see my previous comment.
Hide
Permalink
ERt added a comment -

Workaround:
1. In your local repository find pom which declare inappropriate repository
2. Remember "id" of it repository
3. Add this repository to your pom with same id and url
4. Add <enabled>false</enabled> in <releases> and <snapshots>
5. Add right repository to your pom

Show
ERt added a comment - Workaround: 1. In your local repository find pom which declare inappropriate repository 2. Remember "id" of it repository 3. Add this repository to your pom with same id and url 4. Add <enabled>false</enabled> in <releases> and <snapshots> 5. Add right repository to your pom
Hide
Permalink
Graham Leggett added a comment -

This is a major regression that completely sinks all maven versions newer than v2.2.0, a patch has been available since March, but the patch has been ignored, this bug is unassigned and is marked as "minor".

Is this on the radar for anyone to fix, or has it fallen through the cracks?

Show
Graham Leggett added a comment - This is a major regression that completely sinks all maven versions newer than v2.2.0, a patch has been available since March, but the patch has been ignored, this bug is unassigned and is marked as "minor". Is this on the radar for anyone to fix, or has it fallen through the cracks?
Hide
Permalink
Paul Davis added a comment -

ERt, I tried the workaround and it didn't work for the codehaus cargo module.

I'm with Graham on this one, what's the big deal with getting the patch applied?

Show
Paul Davis added a comment - ERt, I tried the workaround and it didn't work for the codehaus cargo module. I'm with Graham on this one, what's the big deal with getting the patch applied?
Hide
Permalink
Anders Hammar added a comment -

Paul, for a workaround for Cargo, see CARGO-840. I've tried the configuration in that ticket and it does work.

Show
Anders Hammar added a comment - Paul, for a workaround for Cargo, see CARGO-840. I've tried the configuration in that ticket and it does work.
Hide
Permalink
Jesse Glick added a comment -

Confirming that the JRE's implementation does not reliably handle redirects. See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4620571 in the Evaluation section.

Show
Jesse Glick added a comment - Confirming that the JRE's implementation does not reliably handle redirects. See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4620571 in the Evaluation section.
Hide
Permalink
Dennis Lundberg added a comment -

I tried to apply Stephen's patch to wagon trunk, but it fails to apply. Is there any chance that you could update the patch so that it applies cleanly to trunk?

Show
Dennis Lundberg added a comment - I tried to apply Stephen's patch to wagon trunk, but it fails to apply. Is there any chance that you could update the patch so that it applies cleanly to trunk?
Hide
Permalink
Wonne Keysers added a comment -

I can confirm that only version 2.2.0 handles permanent redirects properly.
I would realy recommend including a fix in Maven 3 !

Show
Wonne Keysers added a comment - I can confirm that only version 2.2.0 handles permanent redirects properly. I would realy recommend including a fix in Maven 3 !
Hide
Permalink
Mark Struberg added a comment -

redirects seem to work as expected in wagon-http-lightweight-2.0-SNAPSHOT. There are 4 TCK unit tests for the behaviour now + I tested the functionality against
http://repository.apache.org/content/repositories/snapshots/commons-daemon/commons-daemon/1.0.6-dev-SNAPSHOT

I've deployed the latest wagon-2.0-SNAPSHOT artifacts to the apache.snapshots repository.
Please test the behaviour yourself by adding something like the following snipplet to your pom:

<build>
<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ftp</artifactId>
<version>2.0-SNAPSHOT</version>
</extension>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-http-lightweight</artifactId>
<version>2.0-SNAPSHOT</version>
</extension>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-http</artifactId>
<version>2.0-SNAPSHOT</version>
</extension>
</extensions>
</build>

Show
Mark Struberg added a comment - redirects seem to work as expected in wagon-http-lightweight-2.0-SNAPSHOT. There are 4 TCK unit tests for the behaviour now + I tested the functionality against http://repository.apache.org/content/repositories/snapshots/commons-daemon/commons-daemon/1.0.6-dev-SNAPSHOT I've deployed the latest wagon-2.0-SNAPSHOT artifacts to the apache.snapshots repository. Please test the behaviour yourself by adding something like the following snipplet to your pom: <build> <extensions> <extension> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-ftp</artifactId> <version>2.0-SNAPSHOT</version> </extension> <extension> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-http-lightweight</artifactId> <version>2.0-SNAPSHOT</version> </extension> <extension> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-http</artifactId> <version>2.0-SNAPSHOT</version> </extension> </extensions> </build>
Hide
Permalink
Mark Struberg added a comment -

fixed in r1135334

Show
Mark Struberg added a comment - fixed in r1135334

People

  • Assignee:
    Mark Struberg
    Reporter:
    Grzegorz Slowikowski
Vote (27)
Watch (26)

Dates

  • Created:
    Updated:
    Resolved: