How should a client handle the Location field in an HTTP response when it includes a username and password?

Question

The specification does not mention what to do with the username: password in the URI returned by the position, for example:

Location: http://user: [e-mail] /hidden/pages 

Should we ignore these? . This doesn't seem to make sense, but I was wondering if this would happen (for example, an incorrect server configuration, a strange idea from some administrator / programmer) ..)

 14.30 Location The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server preferred URI for automatic redirection to the resource. The field value consists of a single absolute URI. Location = "Location" ":" absoluteURI An example is: Location: http://www.w3.org/pub/WWW/People.html Note: The Content-Location header field (section 14.14) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the request. It is therefore possible for a response to contain header fields for both Location and Content-Location. Also see section 13.10 for cache requirements of some methods. 

Answer 1

RFC 2617 may be the answer. From section 3.3 :

 ...For example a server could be responsible for authenticating content that actually sits on another server. It would achieve this by having the first 401 response include a domain directive whose value includes a URI on the second server, and an opaque directive whose value contains the state information. The client will retry the request, at which time the server might respond with a 301/302 redirection, pointing to the URI on the second server. The client will follow the redirection, and pass an Authorization header , including the <opaque> data. 

Therefore, I interpret this as meaning that the Location header that you return from the HTTP redirect should not actually contain the user: secret@ part user: secret@ at all, only the rest of the example URL that you gave, and that you (the client) will be responsible for remembering the user / password sent in the Authorization header of the original request that was redirected, and transmit the same header again in the second request.

Update

In addition, RFC 2396 section 3.2.2 contains a few words about the use of user / password in the URL:

 Some URL schemes use the format "user:password" in the userinfo field. This practice is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URI) has proven to be a security risk in almost every case where it has been used.