1 person found this helpful
Here's the RFC: http://www.w3.org/Addressing/URL/url-spec.txt. There is no mention of "length" in it.
Realistically, browsers have limitations on this sort of thing... it might pay to google "firefox maximum URL length" or "IE maximum URL length" etc, to see what their limitations are.
I would say, however, that if you're needing to ask the question, then your URLs are too long. I don't mean that as a simple truism.
What is the circumstance that you find yourself in that warrants asking the question?
Thanks adam,actually i am sending url parameters as dynamic manner after reacing particular values it showing error.any encription techniques are there to send in url parameters?
What is the error it's showing? You don't really explain how it is you are ending up with such long URLs as to cause problems.
And, yes, CF can do encryption. It's in the docs: read 'em, give it a bash, and report back if you have problems. Be mindful of the fact that encrypted strings might contain characters that are not legal in a URL, so will need to be encoded first (also in the docs).
Chandra, I'm afraid that I have no idea what you just said.
URL parameters, as far as I know, are not encrypted even in an HTTPS exchange, because they are considered part of the URL, not part of the message. The body of the message (i.e. POST), on the other hand, is.protected.
I would suggest that you send the request parameters in JSON format, just as you might do with AJAX. This is a well-designed and well-understood protocol with good support on both the client and the server side. (XML is also the same.) This will put the exchange of information within the (encrypted) message body, and it also will permit you to send and to receive structured information ... structs and lists and arrays and so-on.
You still need to be mindful of message sizes, but not nearly so much as with the URL-string.
Any time that you feel you might be "pushing a limit," it's time to assume that "there must be a better way to do this."
URL parameters are inside the SSL envelope and hence protected from a man in the middle. They may be more easily intercepted through a XSS attack.
Thanks a lot....