Bug 613164 - ABRT Support Plugin should follow 305 re-directs
ABRT Support Plugin should follow 305 re-directs
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: abrt (Show other bugs)
6.0
All Linux
urgent Severity urgent
: rc
: ---
Assigned To: Denys Vlasenko
Michal Nowak
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-09 16:56 EDT by Andrew Hecox
Modified: 2013-03-07 21:10 EST (History)
12 users (show)

See Also:
Fixed In Version: abrt-1.1.13-3.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-10 14:33:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed patch (run-tested) (1.95 KB, patch)
2010-08-24 04:56 EDT, Denys Vlasenko
no flags Details | Diff

  None (edit)
Description Andrew Hecox 2010-07-09 16:56:42 EDT
inline with http 1.1, a client should follow 305 re-directs from an initial request using the Location header as the target, without re-interacting with the user:

"
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html:

The requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 responses MUST only be generated by origin servers. 
"

we expect to use this response code to allow location aware file upload locations in the long term and want to ensure all released consumers of API will be able to handle this change.
Comment 2 Denys Vlasenko 2010-07-14 07:33:26 EDT
The code to follow 305 redirects already exists in abrt.
Should I close this bz as CURRENTRELEASE?
Comment 3 Andrew Hecox 2010-07-15 11:22:41 EDT
yes, if the rhplugin follows a 305 on POSTs and GETs, we're good.

I'd rather set to ON_QA so we verify, since I think this will come up in the next 6-9 months.
Comment 4 Denys Vlasenko 2010-07-16 10:33:16 EDT
Ok, setting "Fixed in version" to "abrt-1.1.10-1.el6", even though it definitely happened somewhere before that iirc.
Comment 18 Gavin Romig-Koch 2010-08-16 09:21:35 EDT
Michal, Andrew, I'll talk to Scott about setting up a service we can use to test 305 redirects to webqa.

Michal, I'll send you the details as soon as they are set up.
Comment 21 Gavin Romig-Koch 2010-08-17 08:40:37 EDT
that user/password is correct.  I'm not sure what's wrong.  Please try 
the https://api.access.webqa.redhat.com/rs service (rather than the avalon-ci service, and tell me what response you get.
Comment 22 Michal Nowak 2010-08-18 04:35:34 EDT
Changed to https://api.access.webqa.redhat.com/rs but still:

"""
error in case creation, HTTP code: 401, server says: '401 Unauthorized

This request requires authentication.  Please ensure that you have provided valid BASIC authentication credentials.'
"""
Comment 25 Gavin Romig-Koch 2010-08-20 10:40:32 EDT

The following is a curl version of approximatly what ABRT needs to be doing to webqa to create a case.  If you can run this command from your machine, and it successfully creates a test case, then there is likely a problem in ABRT.  If this command fails, then the problem is in the server, or in the network, or perhaps just in the command.  (Note this has nothing to do with testing or handling the 305 redirect, until we can get the client and server to handle direct creation, testing 305 handling will not be possible):

curl --silent --show-error --insecure --user dhughestest22:redhat -X POST '-HContent-Type: application/xml' --data '<?xml version="1.0" encoding="UTF-8" standalone="yes"?><case xmlns="http://www.redhat.com/gss/strata"><summary>test summary</summary><description>test descriptions</description><product>Red Hat Enterprise Linux</product><version>6.0</version><component>report</component></case>' https://api.access.webqa.redhat.com/rs/cases '-HAccept: text/plain'
Comment 26 Michal Nowak 2010-08-23 07:45:09 EDT
(In reply to comment #25)
> If you can run this command from your machine, and it successfully creates a 
> test case, then there is likely a problem in ABRT.

When I run

curl --silent --show-error --insecure --user dhughestest22:redhat -X POST '-HContent-Type: application/xml' --data '<?xml version="1.0" encoding="UTF-8" standalone="yes"?><case xmlns="http://www.redhat.com/gss/strata"><summary>test summary</summary><description>test descriptions</description><product>Red Hat Enterprise Linux</product><version>6.0</version><component>report</component></case>' https://api.access.webqa.redhat.com/rs/cases '-HAccept: text/plain'

I get: "Thank you for your submission. Case 00231886 has been successfully created."

If we agree this command is correct, there should be bug in 305 redirection bug in abrt. Assigning back to devs.
Comment 27 Gavin Romig-Koch 2010-08-23 08:45:29 EDT
(In reply to comment #26)

> I get: "Thank you for your submission. Case 00231886 has been successfully
> created."
> 
> If we agree this command is correct, there should be bug in 305 redirection bug
> in abrt. Assigning back to devs.

This response is correct.  If ABRT's handling of 305 redirects is correct, one should get the same response when ABRT is configured to point at the 'always 305' server described above in comment #19.
Comment 32 Denys Vlasenko 2010-08-24 04:56:06 EDT
Created attachment 440599 [details]
Proposed patch (run-tested)
Comment 33 Denys Vlasenko 2010-08-24 05:02:16 EDT
The evidence I collected indicates that curl performs redirect automatically if I set CURLOPT_FOLLOWLOCATION option. On code 305 too, even though docs say this option only redirects on 301 and 302.

And curl changes POST to GET unless CURLOPT_POSTREDIR option says otherwise. CURLOPT_POSTREDIR is a "don't change POST to GET" bitmask: bit 0 for 301 and bit 1 for 302. I tried setting it to all-ones, hoping that bit 4 means "do not change POST to GET for 305". Still no luck.

So I disabled automatic redirecting altogether, and open-coded it instead.

See attached patch.

I tested it and it works with:

https://support-services-devel.gss.redhat.com/redirect/ (redirects via 305 to https://api.access.webqa.redhat.com/rs),

https://api.access.webqa.redhat.com/rs (works as-is, not redirects)

http://api.access.webqa.redhat.com/rs (redirects via 301 to https://api.access.webqa.redhat.com/rs (that is, http->https transition))

Looks like we have this one nailed.
Comment 34 Denys Vlasenko 2010-08-24 07:09:30 EDT
Patch is applied to git.
Comment 41 releng-rhel@redhat.com 2010-11-10 14:33:44 EST
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

Note You need to log in before you can comment on or make changes to this bug.