Re: [PHP] _GET('name') truncates
# [EMAIL PROTECTED] / 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
Re: [PHP] _GET('name') truncates
On Tue, February 6, 2007 4:01 pm, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 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. I may well have been remembering HTTP/1.0 or even 0.9 or lower specs. Circa 1995, I suppose... Sorry. That said, I cannot find the exact section I was thinking of from any HTTP spec online, where HTTP implementations were enouraged to make the GET/POST limits as high as practical, but they could not be lower than 1024? for GET and 4096? for POST to be compliant. Maybe I'm even remembering some ephemeral draft or something... I did find this fairly quickly: http://classicasp.aspfaq.com/forms/what-is-the-limit-on-querystring/get/url-parameters.html So even if the server doesn't limit the URL length, SGML, a superset of HTML, does limit it in the actual HREF, according to that one. Utlimately, the specs aren't really all that relevant, since the original poster probably is hitting a limit, whether it's a compliant server or not. I'd love every server to be in spec, but that's not quite the real world we live in, unfortunately. The document you referenced recommends not exceeding 255 characters, for that very reason -- broken proxy servers. Some day I'll find the dang document I'm always remembering when this issue crops up... -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] _GET('name') truncates
Hi all, I've written a php script, called test.php, consisting of the following statements: ?php error_reporting(E_ALL); $query = $_GET['sql']; echo $query; ? Using the script with 'small' values for the parameter sql works fine. Although, using the script with the sql query as specified below http://localhost/test.php?sql=SELECT orders_id, customers_id, customers_name, customers_company, customers_street_address, customers_suburb, customers_city, customers_postcode, customers_state, customers_country, customers_telephone, customers_email_address, customers_address_format_id, delivery_name, delivery_company, delivery_street_address, delivery_suburb, delivery_city, delivery_postcode, delivery_state, delivery_country, delivery_address_format_id, billing_name, billing_company, billing_street_address, billing_suburb, billing_city, billing_postcode, billing_state, billing_country, billing_address_format_id, payment_method, cc_type, cc_owner, cc_number, cc_expires, last_modified, date_purchased, orders_status, orders_date_finished, currency, currency_value FROM orders where ((date_purchased = 18991230 and last_modified is null) or last_modified = 18991230 ) and orders_status in (1,2,3) and ((date_purchased = 20071201203454 and last_modified is null) or last_modified = 20071201203454 ) and orders_id = 2 order by date_purchased results in the following: \SELECT orders_id, customers_id, customers_name, customers_company, customers_street_address, customers_suburb, customers_city, customers_postcode, customers_state, customers_country, customers_telephone, customers_email_address, customers_address_format_id, delivery_name, delivery_company, delivery_street_address, delivery_suburb, delivery_city, delivery_postcode, delivery_state, delivery_country, delivery_address_format_id, billing_name, billing_company, billing_street_address, billing_suburb, billing_city, billing_postcode, billing_state, billing_country, billing_address_format_id, payment_method, cc_type, cc_owner, cc_number, cc_expires, last_modified, date_purchased, orders_status, orders_date_finished, currency, currency_value FROM orders where ((date_purchased = 18991230 and last_modified is null) or last_modified = 18991230 ) and orders_status in (1,2,3) and%2Ãnà I do not understand why the value of the sql parameter is truncated. Any help is appreciated!! Thanks in advance! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] _GET('name') truncates
Ramon wrote: I've written a php script, called test.php, consisting of the following statements: ?php error_reporting(E_ALL); $query = $_GET['sql']; echo $query; ? Using the script with 'small' values for the parameter sql works fine. Although, using the script with the sql query as specified below snip I do not understand why the value of the sql parameter is truncated. Any help is appreciated!! If you really care then you need to sniff the traffic. Chances are that either the browser or server is truncating it. Oh, and please tell me you're not really doing that -Stut -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] _GET('name') truncates
I'll let everyone else do the why the hell are you doing this? security blah blah! bad practice blah blah! type stuff.. I'm sure there will be plenty. One reason this may be happening is, depending on your browser, there's a limit to the number of characters you can have in a URL. That seems to be cutting off around 900 characters. That's a lot to put into a URL. If you're really intent on setting up a PHP powered web page to test SQL statements, I might recommend using a web form either using input type=text or textarea form elements and a POST method instead of GET. If you don't have control over the server but do everything remotely, you might consider seeing if there's a phpMyAdmin set up with your hosting service that you can use for database management/queries/etc. If it's a localish database, you can still use phpMyAdmin, but might also have the option of setting up an ODBC connection and using a program like WinSQL or Navicat to connect and do queries and maintenance. If you have more specific questions about any of this, feel free to ask. -TG = = = Original message = = = Hi all, I've written a php script, called test.php, consisting of the following statements: ?php error_reporting(E_ALL); $query = $_GET['sql']; echo $query; ? Using the script with 'small' values for the parameter sql works fine. Although, using the script with the sql query as specified below http://localhost/test.php?sql=SELECT orders_id, customers_id, customers_name, customers_company, customers_street_address, customers_suburb, customers_city, customers_postcode, customers_state, customers_country, customers_telephone, customers_email_address, customers_address_format_id, delivery_name, delivery_company, delivery_street_address, delivery_suburb, delivery_city, delivery_postcode, delivery_state, delivery_country, delivery_address_format_id, billing_name, billing_company, billing_street_address, billing_suburb, billing_city, billing_postcode, billing_state, billing_country, billing_address_format_id, payment_method, cc_type, cc_owner, cc_number, cc_expires, last_modified, date_purchased, orders_status, orders_date_finished, currency, currency_value FROM orders where ((date_purchased = 18991230 and last_modified is null) or last_modified = 18991230 ) and orders_status in (1,2,3) and ((date_purchased = 20071201203454 and last_modified is null) or last_modified = 20071201203454 ) and orders_id = 2 order by date_purchased results in the following: \SELECT orders_id, customers_id, customers_name, customers_company, customers_street_address, customers_suburb, customers_city, customers_postcode, customers_state, customers_country, customers_telephone, customers_email_address, customers_address_format_id, delivery_name, delivery_company, delivery_street_address, delivery_suburb, delivery_city, delivery_postcode, delivery_state, delivery_country, delivery_address_format_id, billing_name, billing_company, billing_street_address, billing_suburb, billing_city, billing_postcode, billing_state, billing_country, billing_address_format_id, payment_method, cc_type, cc_owner, cc_number, cc_expires, last_modified, date_purchased, orders_status, orders_date_finished, currency, currency_value FROM orders where ((date_purchased = 18991230 and last_modified is null) or last_modified = 18991230 ) and orders_status in (1,2,3) and%2~n~ I do not understand why the value of the sql parameter is truncated. Any help is appreciated!! Thanks in advance! ___ Sent by ePrompter, the premier email notification software. Free download at http://www.ePrompter.com. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] _GET('name') truncates
Ramon-15 wrote: Hi all, I've written a php script, called test.php, consisting of the following statements: ?php error_reporting(E_ALL); $query = $_GET['sql']; echo $query; ? Using the script with 'small' values for the parameter sql works fine. Although, using the script with the sql query as specified below http://localhost/test.php?sql=SELECT orders_id, customers_id, customers_name, customers_company, customers_street_address, ---8--- last_modified = 18991230 ) and orders_status in (1,2,3) and%2Ãnà I do not understand why the value of the sql parameter is truncated. Any help is appreciated!! Thanks in advance! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php i assume you are running into the max size limit(1024?) for $_GET, use _POST instead, furthermore you should apply some security measures! -- View this message in context: http://www.nabble.com/_GET%28%27name%27%29--truncates-tf3176524.html#a8814114 Sent from the PHP - General mailing list archive at Nabble.com. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] _GET('name') truncates
When you send GET all the parameters are sent in the HTTP header and this header has a limited length. If you want to send large parameters in a form you have to use POST which send this data on the HTTP body and it has no limit. On 2/5/07, Ramon [EMAIL PROTECTED] wrote: Hi all, I've written a php script, called test.php, consisting of the following statements: ?php error_reporting(E_ALL); $query = $_GET['sql']; echo $query; ? Using the script with 'small' values for the parameter sql works fine. Although, using the script with the sql query as specified below -- Saludos Oscar -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] _GET('name') truncates
At 3:11 PM -0500 2/5/07, [EMAIL PROTECTED] wrote: That seems to be cutting off around 900 characters. That's a lot to put into a URL. That figure varies. I did some testing on one of my servers and the cut off was somewhere around 7000 characters. However, I don't recommend the practice. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] _GET('name') truncates
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. You also REALLY ought to be using http://php.net/urlencode on the GET args. And if you are spitting that URL out to a browser, you should then use http://php.net/htmlentities on it as well. On Mon, February 5, 2007 12:42 pm, Ramon wrote: Hi all, I've written a php script, called test.php, consisting of the following statements: ?php error_reporting(E_ALL); $query = $_GET['sql']; echo $query; ? Using the script with 'small' values for the parameter sql works fine. Although, using the script with the sql query as specified below http://localhost/test.php?sql=SELECT orders_id, customers_id, customers_name, customers_company, customers_street_address, customers_suburb, customers_city, customers_postcode, customers_state, customers_country, customers_telephone, customers_email_address, customers_address_format_id, delivery_name, delivery_company, delivery_street_address, delivery_suburb, delivery_city, delivery_postcode, delivery_state, delivery_country, delivery_address_format_id, billing_name, billing_company, billing_street_address, billing_suburb, billing_city, billing_postcode, billing_state, billing_country, billing_address_format_id, payment_method, cc_type, cc_owner, cc_number, cc_expires, last_modified, date_purchased, orders_status, orders_date_finished, currency, currency_value FROM orders where ((date_purchased = 18991230 and last_modified is null) or last_modified = 18991230 ) and orders_status in (1,2,3) and ((date_purchased = 20071201203454 and last_modified is null) or last_modified = 20071201203454 ) and orders_id = 2 order by date_purchased results in the following: \SELECT orders_id, customers_id, customers_name, customers_company, customers_street_address, customers_suburb, customers_city, customers_postcode, customers_state, customers_country, customers_telephone, customers_email_address, customers_address_format_id, delivery_name, delivery_company, delivery_street_address, delivery_suburb, delivery_city, delivery_postcode, delivery_state, delivery_country, delivery_address_format_id, billing_name, billing_company, billing_street_address, billing_suburb, billing_city, billing_postcode, billing_state, billing_country, billing_address_format_id, payment_method, cc_type, cc_owner, cc_number, cc_expires, last_modified, date_purchased, orders_status, orders_date_finished, currency, currency_value FROM orders where ((date_purchased = 18991230 and last_modified is null) or last_modified = 18991230 ) and orders_status in (1,2,3) and%2Ãnà I do not understand why the value of the sql parameter is truncated. Any help is appreciated!! Thanks in advance! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] _GET('name') truncates
On Mon, February 5, 2007 2:11 pm, [EMAIL PROTECTED] wrote: If you're really intent on setting up a PHP powered web page to test SQL statements, I might recommend using a web form either using input type=text or textarea form elements and a POST method instead of GET. I belive the minimum compliant POST size is... 4096 bytes??? The HTTP spec upped this every version release, it seems like, so I could never keep track. *MOST* servers are way more lenient on the POST size limit than GET, though, in my experience of servers that enforce a limit. I believe Apahce mod_security may have such a limit -- Actually, that won't even let you pass in something that looks like a whole SQL query in the first place, which is a PITA if you want a back-end admin page with a simple POST form to replace the phpMyAdmin bloatware. :-( -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] _GET('name') truncates
On Mon, February 5, 2007 2:36 pm, Oscar Gosdinski wrote: When you send GET all the parameters are sent in the HTTP header and this header has a limited length. If you want to send large parameters in a form you have to use POST which send this data on the HTTP body and it has no limit. Last time I read the HTTP spec (some years ago, and outdated...) Web server vendors were encouraged to accept as much POST data as practical. To be compliant, they had to accept at least 4K??? This only applies to raw POST, not, say file upload with the ENCTYPE set. If you are certain that it is truly unlimited by RFC Spec, I'd love a reference... -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
