[
http://jira.codehaus.org/browse/WAGON-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260970#action_260970
]
Brett Porter commented on WAGON-322:
------------------------------------
makes sense to me, the lack of additional information is regularly confusing to
users, training classes, etc.
> The HTTP Wagons should use Reason-Phrase sent in HTTP Response and use that
> in exception message (at least incorporate it)
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: WAGON-322
> URL: http://jira.codehaus.org/browse/WAGON-322
> Project: Maven Wagon
> Issue Type: Improvement
> Reporter: Tamás Cservenák
>
> The HTTP Wagons should use Reason-Phrase sent in HTTP Response and use that
> in exception message (at least incorporate it).
> This would enable MRMs to at least "hint" somewhat Maven users why it's
> responding with some error.
> Typical example: Maven users using Nexus (but I believe is true for other
> MRMs too), tend to "forget" about having pull and push URLs different (you
> usually pull from "groups", and push/deploy to actual reposes). With wrong
> URL, your build will fail, and Maven message on CLI will state "server
> responded with code 400" (in case of Nexus, it will respond with Bad Request,
> since groups are read-only).
> Usually, the end user (and Maven) have no clue why the request was rejected,
> and user has to start investigating about the problem. On the contrary, the
> server side MRM actually knows very well what the problem is: deploy tried to
> read-only target, redeployment tried but redeploying is forbidden, deploy of
> a snapshot tried to a release repository, etc. All of these results with same
> error code (in case of Nexus): with HTTP 400, but without any explanation
> shown on client side.
> If Wagon -- I am not sure about the details -- would somehow incorporate the
> _actual_ Reason-Phrase got from server/MRM, and make Maven display it as part
> of the message about failed build, it would be much-much easier to realize
> why the build failed, it will be told by the MRM who actually rejected the
> request.
> By HTTP/1.1 RFC, the Reason-Phrase is unbound, it might have _any_ content
> (except CR LF), exactly for these cases.
> http://tools.ietf.org/html/rfc2616#section-6
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
