9.8. Relative Paths
The server should be careful of ".." path segments in the request
URI. These should be removed or resolved in the request URI before
it is split into the script-path and extra-path. Alternatively, when
the extra-path is used to find the PATH_TRANSLATED, care should be
taken to avoid the path resolution from providing translated paths
outside an expected path hierarchy.
9.9. Non-parsed Header Output
If a script returns a non-parsed header output, to be interpreted by
the client in its native protocol, then the script must address all
security considerations relating to that protocol.
10. Acknowledgements
This work is based on the original CGI interface that arose out of
discussions on the ’www-talk’ mailing list. In particular, Rob
McCool, John Franks, Ari Luotonen, George Phillips and Tony Sanders
deserve special recognition for their efforts in defining and
implementing the early versions of this interface.
This document has also greatly benefited from the comments and
suggestions made Chris Adie, Dave Kristol and Mike Meyer; also David
Morris, Jeremy Madea, Patrick McManus, Adam Donahue, Ross Patterson
and Harald Alvestrand.
11. References
11.1 Normative References
[1] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[2] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI) : Generic Syntax", RFC 2396, August 1998.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirements
Levels", BCP 14, RFC 2119, March 1997.
[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[5] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[7] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal
IPv6 Addresses in URL’s", RFC 2732, December 1999.
[8] "HTTP Status Code Registry",
http://www.iana.org/assignments/http-status-codes, IANA.
[9] "Information Systems -- Coded Character Sets -- 7-bit American
Standard Code for Information Interchange (7-Bit ASCII)", ANSI
INCITS.4-1986 (R2002).
[10] "Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/IEC
8859-1:1998.
11.2. Informative References
[11] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
Unifying Syntax for the Expression of Names and Addresses of
Objects on the Network as used in the World-Wide Web", RFC 1630,
June 1994.
[12] Braden, R., Ed., "Requirements for Internet Hosts -- Application
and Support", STD 3, RFC 1123, October 1989.
[13] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[14] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[15] Hinden R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[16] Masinter, L., "Returning Values from Forms:
multipart/form-data", RFC 2388, August 1998.
[17] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, November 1987.
[18] Raggett, D., Le Hors, A., and I. Jacobs, Eds., "HTML 4.01
Specification", W3C Recommendation December 1999,
http://www.w3.org/TR/html401/.
[19] Rescola, E. "HTTP Over TLS", RFC 2818, May 2000.
[20] St. Johns, M., "Identification Protocol", RFC 1413, February
1993.
[21] IBM National Language Support Reference Manual Volume 2,
SE09-8002-01, March 1990.
[22] "The Common Gateway Interface",
http://hoohoo.ncsa.uiuc.edu/cgi/, NCSA, University of Illinois.
12. Authors’ Addresses
David Robinson
The Apache Software Foundation
EMail: drtr@apache.org
Ken A. L. Coar
The Apache Software Foundation
EMail: coar@apache.org
13. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and at
www.rfc-editor.org, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the ISOC’s procedures with respect to rights in ISOC Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.