# ceo@xxxxxxxxx / 2007-02-05 18:09:21 -0600: > GET args can be truncated at some number, if the server does not want > to allow longer args. I believe the minimum compliant limit is 1024 > bytes. Since you asked for a reference in the other post: HTTP/1.1 tries to be as general as possible, and doesn't impose limits on line lengths. Some commented quotes follow, I hope it's digestible. # 3.2.1 General Syntax # # URIs in HTTP can be represented in absolute form or relative to some # known base URI [11], depending upon the context of their use. The two # forms are differentiated by the fact that absolute URIs always begin # with a scheme name followed by a colon. For definitive information on # URL syntax and semantics, see "Uniform Resource Identifiers (URI): # Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs # 1738 [4] and RFC 1808 [11]). This specification adopts the # definitions of "URI-reference", "absoluteURI", "relativeURI", "port", # "host","abs_path", "rel_path", and "authority" from that # specification. RFC 2396 doesn't mention any length limits. # The HTTP protocol does not place any a priori limit on the length of # a URI. Servers MUST be able to handle the URI of any resource they # serve, and SHOULD be able to handle URIs of unbounded length if they # provide GET-based forms that could generate such URIs. Case closed. If there's no "a priori limit on the length of a URI", then there isn't any limit on the length of the request line, the Location response header, or the Content-Location entity header. # A server # SHOULD return 414 (Request-URI Too Long) status if a URI is longer # than the server can handle (see section 10.4.15). "10.4.15 414 Request-URI Too Long" doesn't add anything interesting. # 4 HTTP Message # # 4.1 Message Types # # HTTP messages consist of requests from client to server and responses # from server to client. # # HTTP-message = Request | Response ; HTTP/1.1 messages # # Request (section 5) and Response (section 6) messages use the generic # message format of RFC 822 [9] for transferring entities (the payload # of the message). The keyword is "entities". Applying the email-specific header length limit to a HTTP implementation would IMO be a mistake. For completeness, RFC 822: # 3.4.8. FOLDING LONG HEADER FIELDS # # Each header field may be represented on exactly one line con- # sisting of the name of the field and its body, and terminated # by a CRLF; this is what the parser sees. For readability, the # field-body portion of long header fields may be "folded" onto # multiple lines of the actual field. "Long" is commonly inter- # preted to mean greater than 65 or 72 characters. The former # length serves as a limit, when the message is to be viewed on # most simple terminals which use simple display software; how- # ever, the limit is not imposed by this standard. As you can see, the standard specifically disclaims a length limit. The 998-character limit you mentioned (IIRC) in another post comes from RFC 2822 (replaces 822), which imposes it for compatibility with legacy systems which could not handle lines longer than 1000 characters (RFC 2822, 2.1.1. Line Length Limits): # The 998 character limit is due to limitations in many implementations # which send, receive, or store Internet Message Format messages that # simply cannot handle more than 998 characters on a line. Receiving # implementations would do well to handle an arbitrarily large number # of characters in a line for robustness sake. This limitation doesn't apply to HTTP, that'd conflict with the unbound URI statement in 3.2.1. As for the server side: Status codes 413 and 414 are SHOULD, but any server which silently truncates either the request URI or the request entity has serious interoperability problems. Summary There are no limits on line length in HTTP, servers need to be able to handle anything they need to work, and clients need to support headers as long as they want to send. HTTP/1.1 doesn't address URI or entity truncation in user agents specifically, that's simply a bug, not a protocol violation. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
