HTTP/1.x protocol suite.
The Safe response header field is used by origin servers to indicate
whether repeating the received HTTP request is safe in the sense of
Section 9.1.1 (Safe Methods) of the HTTP/1.1 specification [1]. For
the purpose of this specification, a HTTP request is considered to be
a repetition of a previous request if both requests
RFC 2310 The Safe Response Header Field April 1998
- are issued by the same user agent, and
- apply to the same resource, and
- have the same request method, and
- both have no request body, or both have request bodies which are
byte-wise identical after decoding of any content and transfer
codings.
The Safe header field has the following syntax.
Safe = "Safe" ":" safe-nature
safe-nature = "yes" | "no"
An example of the header field is:
Safe: yes
If a Safe header field is absent in the response, the corresponding
request MUST be considered unsafe, unless it is a GET or HEAD
request. As GET and HEAD requests are safe by definition, user
agents SHOULD ignore a `Safe: no' header field in GET and HEAD
responses.
If, according to a received Safe header field, the repeating of a
request is safe, the request MAY be repeated automatically without
asking for user confirmation.
5 Security Considerations
For a discussion of the security considerations connected to HTTP
form submission, see [1]. The Safe header field introduces no new
security risks.
The use of GET requests for form submission has some security risks
which are absent for submission with other HTTP methods. By taking
away a counter-incentive to the use of GET requests for form
submission, the Safe header field may improve overall security.
RFC 2310 The Safe Response Header Field April 1998
6 References
[1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and
T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2068, January 1997.
[2] Nebel, E., and L. Masinter, "Form-based File Upload in HTML",
RFC 1867, November 1995.
[3] Yergeau, F., Nicol, G., Adams, G., and M. Duerst,
"Internationalization of the Hypertext Markup Language", RFC
2070, January 1997.
7 Author's Address
Koen Holtman
Technische Universiteit Eindhoven
Postbus 513
Kamer HG 6.57
5600 MB Eindhoven (The Netherlands)
EMail: koen@win.tue.nl
=2= |