Just a thought: Is there a limit on url string?
-
:) Nice sig, btw. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Somebody noticed. Yay! :-D
Driven to the ARMs by x86.
-
Somebody noticed. Yay! :-D
Driven to the ARMs by x86.
-
im not sure what it STANDS for, but i do know its the processor architecture used in many mobile phones, which stands in opposition to x86/x64. as for the topic, i frikken hate url string limits...namely the limits on data uri that MS imposes. the browser neednt enforce url limits as long as the server enforces limits. the server will only accept x characters so the browser will only send x characters (since the first part is establishing a socket, then client sends a pack, the server accepts, and then the client sends another. it doesnt send the entire url and then the server acks parts of it at a time as far as i know) so there isnt the risk of someone DOSing someone with a long url. IE8's limit on data URI length (from what i understand they have thankfully increased this in 9, but if you are depending on these for a WebBrowser object in .net 4.0 you are SOL) has been a thorn in my side for some time.
-
Maximum URL length is 2,083 characters in Internet Explorer. AFAIK that would be for IE7. You might also take a look at article 904846 but those numbers are probably made up.
-
ARM = Advanced RISC Machine RISC = (This was the operating system first used by Acorn after the BBC Master in the 1980's) R.I.S.C. = Reduced Instruction Set Computer EG. The processor would run faster because the list of machine code commands was shorter.
-
-
If Opera can handle up to 190,000 characters, but servers can only handle up to 16,384 characters, how can you test Opera with a URL longer than 16,384 characters? :~
Mark AJA wrote:
but servers can only handle up to 16,384 characters
That's the default limit in IIS. I expect it can be configured to be higher. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
im not sure what it STANDS for, but i do know its the processor architecture used in many mobile phones, which stands in opposition to x86/x64. as for the topic, i frikken hate url string limits...namely the limits on data uri that MS imposes. the browser neednt enforce url limits as long as the server enforces limits. the server will only accept x characters so the browser will only send x characters (since the first part is establishing a socket, then client sends a pack, the server accepts, and then the client sends another. it doesnt send the entire url and then the server acks parts of it at a time as far as i know) so there isnt the risk of someone DOSing someone with a long url. IE8's limit on data URI length (from what i understand they have thankfully increased this in 9, but if you are depending on these for a WebBrowser object in .net 4.0 you are SOL) has been a thorn in my side for some time.
A TCP packet is not likely to contain only one character of data. A URL is quite small enough, ordinarily, to fit within a single packet, and it would be very strange and inefficient to split it up into single-character chunks. I also think you might be confusing different layers of the network stack. IIS doesn't know anything about packets or acking. That happens at the TCP layer and below. IIS merely sees the request as an ordered data stream from which it reads until hitting the sequence of characters indicating the end of the request, and then responds to that request. It may well close the TCP connection if it keeps reading and reading and the request turns out to be too long, or send a response and then close the connection even sooner if the URL portion of the request is too long (a total request could be very long if a POST is involved), but there isn't some kind of byte-by-byte acceptance response from IIS to the browser. Typically IIS doesn't even send anything at all (although the underlying TCP mechanisms are sending packets in both directions) until the whole request is complete.