11.07.2015 Views

Network Working Group R. Fielding Request for Comments: 2616 ...

Network Working Group R. Fielding Request for Comments: 2616 ...

Network Working Group R. Fielding Request for Comments: 2616 ...

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

whose version is HTTP/1.0 or lower, then the sender MUST include ineach warning-value a warn-date that matches the date in the response.If an implementation receives a message with a warning-value thatincludes a warn-date, and that warn-date is different from the Datevalue in the response, then that warning-value MUST be deleted fromthe message be<strong>for</strong>e storing, <strong>for</strong>warding, or using it. (This preventsbad consequences of naive caching of Warning header fields.) If allof the warning-values are deleted <strong>for</strong> this reason, the Warning headerMUST be deleted as well.14.47 WWW-AuthenticateThe WWW-Authenticate response-header field MUST be included in 401(Unauthorized) response messages. The field value consists of atleast one challenge that indicates the authentication scheme(s) andparameters applicable to the <strong>Request</strong>-URI.WWW-Authenticate = "WWW-Authenticate" ":" 1#challengeThe HTTP access authentication process is described in "HTTPAuthentication: Basic and Digest Access Authentication" [43]. Useragents are advised to take special care in parsing the WWW-Authenticate field value as it might contain more than one challenge,or if more than one WWW-Authenticate header field is provided, thecontents of a challenge itself can contain a comma-separated list ofauthentication parameters.15 Security ConsiderationsThis section is meant to in<strong>for</strong>m application developers, in<strong>for</strong>mationproviders, and users of the security limitations in HTTP/1.1 asdescribed by this document. The discussion does not includedefinitive solutions to the problems revealed, though it does makesome suggestions <strong>for</strong> reducing security risks.<strong>Fielding</strong>, et al. Standards Track [Page 150]RFC <strong>2616</strong> HTTP/1.1 June 199915.1 Personal In<strong>for</strong>mationHTTP clients are often privy to large amounts of personal in<strong>for</strong>mation(e.g. the user's name, location, mail address, passwords, encryptionkeys, etc.), and SHOULD be very careful to prevent unintentionalleakage of this in<strong>for</strong>mation via the HTTP protocol to other sources.We very strongly recommend that a convenient interface be provided<strong>for</strong> the user to control dissemination of such in<strong>for</strong>mation, and that

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!