Artifacts are uploaded twice in the case of HTTP redirection

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Won't Fix
  • Affects Version/s: 1.0-beta-6
  • Fix Version/s: None
  • Component/s: wagon-http
  • Labels:
    None
  • Environment:
    Debian unstable, Sun JDK 6.0u14

Description

When deploying to an HTTP (not DAV) repository, if the request is redirected, the artifact is uploaded twice: once for the original request, and then again at the redirect location.

Please consider using "Expect: 100-continue" when uploading, so as not to waste bandwidth in the case of a redirect. See RFC 2616 section 8.2.3.

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. WAGON-314 Permament move (error 301) not handled properly by Lightweight HTTP Wagon

  • 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.
relates to

Bug - A problem which impairs or prevents the functions of the product. WAGON-277 HttpClient wagon (wagon-http) uploads all files twice when preemptive authentication is disabled

  • Critical - Crashes, loss of data, severe memory leak.
  • 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
John Casey added a comment -

This is a problem in the httpclient-driven wagon, which is what we defaulted to in maven 2.2.0

Show
John Casey added a comment - This is a problem in the httpclient-driven wagon, which is what we defaulted to in maven 2.2.0
Hide
Permalink
Mark Struberg added a comment -

Actually it's not a problem imo.

Using the 100-continue mechanism would mean that every request would need to be sent twice!
The 100-continue logic is to send a request upfront if the server is willing to accept the data at all. The server will most likely respond with a HTTP_CONTINUE (100) ret code. In this case the client sends the real request.

IF we'd like to implement that, then it would only make sense to do this solely for big uploads. Which is a bit of a problem for the stream based wagons.

Show
Mark Struberg added a comment - Actually it's not a problem imo. Using the 100-continue mechanism would mean that every request would need to be sent twice! The 100-continue logic is to send a request upfront if the server is willing to accept the data at all. The server will most likely respond with a HTTP_CONTINUE (100) ret code. In this case the client sends the real request. IF we'd like to implement that, then it would only make sense to do this solely for big uploads. Which is a bit of a problem for the stream based wagons.
Hide
Permalink
Mark Struberg added a comment -

read more over at httpclient4 https://issues.apache.org/jira/browse/HTTPCLIENT-889

Show
Mark Struberg added a comment - read more over at httpclient4 https://issues.apache.org/jira/browse/HTTPCLIENT-889

People

  • Assignee:
    Mark Struberg
    Reporter:
    Alex Hvostov
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: