What is the maximum length of a URL for each browser?
Is a maximum URL length part of the HTTP specification?
Short answer - de facto limit of 2000 characters
If you keep URLs under 2000 characters, they'll work in virtually any combination of client and server software.
If you are targeting particular browsers, see below for more details on specific limits.
Longer answer - first, the standards...
RFC 2616 (Hypertext Transfer Protocol HTTP/1.1) section 3.2.1 says
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. 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).
That RFC has been obsoleted by RFC7230 which is a refresh of the HTTP/1.1 specification. It contains similar language, but also goes on to suggest this:
Various ad hoc limitations on request-line length are found in
practice. It is RECOMMENDED that all HTTP senders and recipients
support, at a minimum, request-line lengths of 8000 octets.
...and the reality
That's what the standards say. For the reality, there was an article on boutell.com (link goes to Internet Archive backup) that discussed what individual browser and server implementations will support. The executive summary is:
Extremely long URLs are usually a
mistake. URLs over 2,000 characters
will not work in the most popular web
browsers. Don't use them if you intend
your site to work for the majority of
Internet users.
(Note: this is a quote from an article written in 2006, but in 2015 IE's declining usage means that longer URLs do work for the majority. However, IE still has the limitation...)
Internet Explorer's limitations...
IE8's maximum URL length is 2083 chars, and it seems IE9 has a similar limit.
I've tested IE10 and the address bar will only accept 2083 chars. You can click a URL which is longer than this, but the address bar will still only show 2083 characters of this link.
There's a nice writeup on the IE Internals blog which goes into some of the background to this.
There are mixed reports IE11 supports longer URLs - see comments below. Given some people report issues, the general advice still stands.
Search engines like URLs < 2048 chars...
Be aware that the sitemaps protocol, which allows a site to inform search engines about available pages, has a limit of 2048 characters in a URL. If you intend to use sitemaps, a limit has been decided for you! (see Calin-Andrei Burloiu's answer below)
There's also some research from 2010 into the maximum URL length that search engines will crawl and index. They found the limit was 2047 chars, which appears allied to the sitemap protocol spec. However, they also found the Google SERP tool wouldn't cope with URLs longer than 1855 chars.
CDNs have limits
CDNs also impose limits on URI length, and will return a 414 Too long request when these limits are reached, for example:
Fastly 8Kb
CloudFront 8Kb
CloudFlare 16Kb
(credit to timrs2998 for providing that info in the comments)
Additional browser roundup
I tested the following against an Apache 2.4 server configured with a very large LimitRequestLine and LimitRequestFieldSize.
Browser Address bar document.location
or anchor tag
------------------------------------------
Chrome 32779 >64k
Android 8192 >64k
Firefox >64k >64k
Safari >64k >64k
IE11 2047 5120
Edge 16 2047 10240
See also this answer from Matas Vaitkevicius below.
Is this information up to date?
This is a popular question, and as the original research is ~14 years old I'll try to keep it up to date: As of Jan 2021, the advice still stands. Even though IE11 may possibly accept longer URLs, the ubiquity of older IE installations plus the search engine limitations mean staying under 2000 chars is the best general policy.
The longest URLs I came across are data URLs
Example image URL from Google image results (11747 characters)
data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wCEAAkGBhQSERIUExQUFRUUFxcXFhQYFBQXGBgYFhkVGBkVFxUXHCYfGBojGRQVHy8gJCcpLCwsFh4xNTAqNSYrLCkBCQoKDgwOGg8PGiokHyQpLDUqKSwsLCksKSwpKSwsLCwpKSkpLCwpLCksKSwpLCkpLCwsLCkpKSwsLCwsLDQsLP/AABEIAM0A9gMBIgACEQEDEQH/xAAcAAACAgMBAQAAAAAAAAAAAAAABQQGAgMHAQj/xABTEAACAAQCBAcLBgsFBwUAAAABAgADBBESIQUGMUEHEyJRYYGRFBYyVHF0lKGxs9IjNEKS0dMXMzVSYmRypMHj8GOTo7LiJENzosLh8RVTgoPD/8QAGQEBAAMBAQAAAAAAAAAAAAAAAAECAwQF/8QAJxEAAgIBAwMEAgMAAAAAAAAAAAECEQMSITEEE0EiUWGBkfAyceH/2gAMAwEAAhEDEQA/AOiaq6q0b0NGzUlMzNTySWMiUSSZaEkkrmbw17z6LxOl9HlfDBqf8wovNpHu0hvACjvPovE6X0eV8MHefReJ0vo8r4YbwQAo7z6LxOl9HlfDB3n0XidL6PK+GG8EAKO8+i8TpfR5Xwwd59F4nS+jyvhhsTaKnX69gzGlUiCc6+FMZsMpTuBYAlj0LnFoxcuCG0ht3n0XidL6PK+GDvPovE6X0eV8MIX0jpQ8pe5SPzeKndmLFl2QuPCpMpnwV1Pg345ZuLc4DbfbG0enlJelp/ZR5EuS3959F4nS+jyvhg7z6LxOl9HlfDDCjrFmosxCSrgMLixsdmRzEb45zQUd59F4nS+jyvhg7z6LxOl9HlfDDeCAFHefReJ0vo8r4YO8+i8TpfR5Xww3ggBR3n0XidL6PK+GDvPovE6X0eV8MN4IAUd59F4nS+jyvhg7z6LxOl9HlfDDeFOsNVMlSmmI1gguRhBJ6zsispaVZWclGLkzzvPovE6X0eV8MHefReJ0vo8r4YR8HOsM6slzZk1sXyhC5KoVRsGQuTe+fRFzhGWpJkQlripIUd59F4nS+jyvhg7z6LxOl9HlfDDeCLFxR3n0XidL6PK+GDvPovE6X0eV8MTarSUuX4TAHm2nsELn1vkA/T8uA/8An1RFommbO8+i8TpfR5Xwwd59F4nS+jyvhiTRabkzckcE82w9hibeJIFPefReJ0vo8r4YO8+i8TpfR5Xww3ggDlfDJoCmk0MppVPIlsahRdJUtDbi5xsSq7LgZdEET+HL8nyvOU93OggC3an/ADCi82ke7SG8KNT/AJhRebSPdpDeACCCCACCCCAKJwqawtIpxKlmzzSF+sbD7Yaal6spTyJeWdt/PvY/pE3zig8LVYe7pSnwZZlP1XzPqMdfoyMC22WFvJHZnjoxwS8qzDG9UpG20J9YNWJVWJfGC5ltiXmB57b4cXjwuI5E2uDdmqlplloFXYP6vCys1slI5lqHmzB4SSlxlf2jsXtjXrjpjuelmMu2xAPNkbwk4M9HiZRS5r5mZdzfezE3Y9OQjFybnpR0RxKOLuy8ukNqTXymeZxTFpT3ACzVKZndfZ64sQaKRwk6qpOpjNVbTJViLb1ORB6M7xp4NdZ2mULrNbE9OxTEdpXIrfpAyjKWftatfhWbz6eMsKzY/emvZ/BcazSySzhJJb81QS3YI0S9Y5RNiSh/SFor2qMs1Lz5sw35ZFvJYAeS1oe6Y0KjSyVADKLgjo3Rjrzyw92LV1aVePa/c5tMVLSyfWKXlOEbCzIwVttiQQG6iQYrmite0s0qpWZKnyrK6lGYMdheWUBxKduwbYhauadaUKqSxvxKmYnQLG69RF+uIPBtO7parmOxLcacWZuRYYc+a149Ho5xz9P3mttjnypwyaCfrFwlyUllJAmTJrghbIbKdmJt+V72tfKGOkq7jNGs3K/FgXZcJa1gWwnMXil8LGglpml1cnkNfOxPhLmrdYuOuLdpScH0WXC4caKxHSbXjbq4QWBSh5TOWUpOM78IW8Dy2o2PPMf/ADGLTpLWWVJYIcTzCL8XLUs1ucgZAeUxTuDOr4rRkx/zS568RiHqTpRWFTOmiZMZpzDAiMxbCAADuA8pG0xwRnUYx+D0elwt4VNq+FXyXGh16ppk0SSWlzDkEmLhueYHZG/SGlicSICtiQW+G0UzT2hGrp0l3lrTy0a5UHFNcAg2YryU2biTFolSYjuSTaZ05MOPZw9t1zT+GaHpYW1VHDubkIV1c6M3ImMCu18gizC4YG9wbeyLFqhrizsJM7Nrch/zug9Iiu11VmemFAurFkyIs6nmYfbGkMjM54juAa+cewk1V00KiQjjeBlzHeIdx0nIc64cvyfK85T3c6CDhy/J8rzlPdzoIAt2p/zCi82ke7SG8KNT/mFF5tI92kN4AIIIIAIIIIA5zwvauNNlJUS1uZV1mAbcBzDdRHYY38GOuizpCU01gJ0sYVufxiDYQd7AZERfZksMCDmDkRHPNYOCWW7mZTM0lib2U5X6Bu6o7YZsc8fay+OGYSxyUtUToM6XiBFyLjaDYjyHdHONddCGkp3mynYFib3dmOYO0sY3UGh9LSrKatmX9KUjntOcStJ6lz6xQtTPmOozwnBLW/OVQXPbEYWsM1LVa+xNOaqtxBRaPmT9X1KZsLzCMyW24yScybeyHHA9plXpWpyRjkMbDeUOYbtuItmrugVpadZK+CosN+XXCHSXBtKM7j5BaRMOZaWxTM7TzdUcE05ZHkR6WLLHsdia/p+w41x0ikmjnO5AGGw6SbWA6YpvBroRxSVDlbNOYuFP/KPqj1xYU1JDlTOZpjLseY5mEdKqeSD1RZqWjWWoVRYe3yxnPEsl6/KojvaMfbg/Nsp2olUEnTpRyxHGvl2FfLleLjVTQqszEAAG5hJpjVBZr8ZLJlvzqbZ88Ytq7MmLhmuXH6TXH1RYHrjnxY82LH2tnWyfx8ozlKMpaiv6o0gqKmpmkXlODLAI2oARfrv6oXaO0BV6KqneSFm0z3xBiQcIzBuAeUBlsi+VE6TQU7OfBXM2tdjuivUWl6ytXEjLJlsMlWWJj2OwsznCMtwEel0WN9Ph7afo4d+f9ObM1OV+RRPqzpqfxZssqnYHiwTy2P03O3CN1t8W7WemEvR8xBsVR7Y5vpnVSr0a/dUh3IBzay4gDnZlXJlPNF/oXl6X0chcEY/CUMygOhIOzMi49cb9biUoasT9PC+DnqUoyxtb0JODSk43Rc1B9IzFBvvubeu0V7g802tLUzqaq5CzGPhbFm3sQ3QRsPRF+1a1IWiYmWzWP0cb4c/0L2v02jXrXweSK04yMEze6mxNufceuPMeOXpa5R6vR5owxPDmWzrjw15J+lVXFKC2w2JFrW5oJZGy47YqWh9Adz8bIEyYSrjGWYEgYTYIdwNt0LNKz6FTKOCdeYSEYTJlmNyuR35g5gWy2xST1S3NIxUVtx+C/T5eUVzTFRLl+G6qL2zYCJU6rEulZgzWOdjmRkMrxR9HFKlsU2Xju1uUSVHlF7DymKVZpdGVfpaVc4ZinyGIPddwc/6Ee6T09Yuq0glKpw/ixn0hgPbzQvH5wyB3RpwZ6tzofBlWZMm4MfWL/wAY6VHHNQtIKk4KTYuSV6cIF/bHYZZuB5I6Yu0ck/5M55w5fk+V5ynu50EHDl+T5XnKe7nQRYoW7U/5hRebSPdpDeFGp/zCi82ke7SG8AEEEEAEEYlxzxlABBBBEALQR5eAGJB7BBBABBBBEALQQXgiQVDhO0TNn0TCVclTdkG1lNwcPSL36oS6k8ItOlOkmovJmSxhJZGCtawBFhkbbiI6QVhbU6uyHNymcdEcq0aJq0uK2Zk4PVqiV3T2tcupkTJNIGnNMUqXwsstAcsbuw3bgLkwy1E0GaWlWWTf+JOZPrhrI0NLS1lvbZck2iaIylNadK2RdR3t8nsEEEULFWnSFM+ffeQD2GMpuhlIAsAo5gBlzXHkjXpCdhqnXebPboNgD2gxPefYZ9sceTaTO7FehFU10YrTHDsJt1C32RSdXp9mYc8XjWqtx0zIsss+wEbL3238m6KBTKUmLjBUre/ST7ILgv53LXO0YHF3ucss4q+l1Cmw2RapGkA6AA8q2Qio6Xzc9Bt5TviIkzqtjdq4v+105uLhZuEb7MLE2/8AjHdtHNeWvkjiuq9F8tKJWzIGud/KyC+2O2UIsijojpx8HL1D9X0UHhy/J8rzlPdzoIOHL8nyvOU93OgjQ5y3an/MKLzaR7tIbwo1P+YUXm0j3aQ3gCp8KdS0vRdSyMUYcVZlYoRedKB5S5jK+fNCXSOsLUFItTK4ppMuotULIqHrCUZCos80DAwcrcXAtvztHRHlgixAI5js7IwSlQAgKoB2gAAHqEAcb1jrp7tR90CWZz0tHMdwmFrtpCRZM7WADLdbbRHaYwaSpNyATzkA9PtzjOAPGin1MyeJkyWhc8TNaoOZJeW9mSWoxb7zkCnI8Xui4GFj6GYknuioF9wMrs/F7I0xSUW7IZUqXWGeJrWayvNWZLVmk2aXNK2/GNxjDDcjixbMb7xP1O0g1qWWJqTVMi7KoT5EyxLCqcJJucTA4t6mwEO//QDcHuifcbDeTl5PkozpdCYGDCdOyIJHyVjbcbSwbdcdE8uOUaVfv0VpjSFGtrgUNUS2G0qYQwYoQQpIswIINwN8N4iV9FxoAxug34cGfQcStHLFpSVlytz9IzhMKypwWWJlPJQBUfKbLU8YHa5Yi5tckZb4j6R1pmJIQ4ysxePJ+bqr8U8xFznEXJ4u5CZjF5IsI0EfGKjtlbtn+6jFtXyds+efKZJ27dsqOpTx7N1+/RSmIpeskwvKPGqWeZNU02BclSXOZGvbGL8WhF9uI2vEGVrTUMFJmqqsoZrzKLjFY4TgRceG1i1+Ms1lFhe8WQaorxvG8fUl+czVIGWG4QphBsSLgXzPOY3HVz+3n/4Pb+Ki/cwrwvwKYxoJuKWjXJxKpuy4WNwDcr9E9EbzGumk4VClmaw8JrXPSbAC/VG0xwMuUzTdVhaod85stxxEsz5kktLCI15SrcTH4zGNhvax6d0zSk/C7tNVENS8gHAlpUtHmDjGZrgnkgXPJswyvnDifoQs2Ljp4zuADK5PQt5ZIGXPGJ0ESCO6J9t4vK9nFR1KcKVlXYiXWp0l1Reah4uU5kTCFHGspnDGoGT5LLyUWj06wzcb2nSrrPWWJBCg4GWXd3+kApcm4ysM7xP0nSS5CY5lTPAXwR8iTnuUcXHONIaVeYZhQnAz48LsCS1gCWZFG4DLYIs8mKm0v38EVItNPrJLngo08PPWYFw/I3HJJKq0o2I6Cb7Lw7Zi6qVwm4yxXtfdsjiOg+TxyDkTVmNMA27TiRhzi/tMdH1a1pWalm5MxTy0/wCpT+bv6I8zqPVLUkd2HZUT5GlFbkTJ3EzACcJkckEEA4XPhWvz3is611AViEm8cxa2Li1VQNoNx4RzbZvt5YtdUVmqWlulmzuAHUkb7g7coqWkKeWXzmYiLliLBcs7WG0xlqS2OpRT3Na4ZUlXxctLn9okWAPRe3ZCCvqklhTNJCKQXa1zcnM2G2NldX3O3krdid2UUjTmluOLAeABl0n84xeKt2c8nsz6C1Nl0tQomSJsqYciQrAsLD6S7Rs5ovKCwA5o+KqKodGDS2ZGGYZWKkeQjOOj6tcLmkaeweYJ6fmzRdrc3GDPtvHSculs6Xw5fk+V5ynu50EUzhA4S5VdQy0Mt5UxZyuRcMpASaDZh0sNoggZ7nYdT/mFF5tI92kR6/TdQKlpEiTLmYZaTCzzTL8MstvAN/AMSNT/AJhRebSPdpEel/KlR5tI95OgSed31/itP6UfuoO76/xWn9KP3UWCCAK/3fX+K0/pR+6g7vr/ABWn9KP3UWCCAK/3fX+K0/pR+6g7vr/Faf0o/dRYIIAr/d9f4rT+lH7qDu+v8Vp/Sj91FgggCv8Ad9f4rT+lH7qDu+v8Vp/Sj91FgggCv931/itP6UfuoO76/wAVp/Sj91FgggCv931/itP6UfuoO76/xWn9KP3UWCCAK+dIV/itP6UfuoS13CBOlXvJp2I2hKh2PqlW9cMtfdYVppABcIZmWInYv0j6wOuOYStYqViAJ8u53YhEWTRbDwutn/swv0zPblC6o4VKt/ASVLHkZj2kj2QrqKVZq4kYXGxgb9ttxiFTycQOQBU2ZeY/YYgskGlNM1E9g05yencOgAbI1Sap9jHLyf1eJiy4yFOPsgSJNJ6NLMsxDZl2Hy7jDvRmqM+fKE2eDIyay3znZHaV5UuWd9uVDLQmjONmiw5KWLeXaF8tob6114lSWNwMKk3PPuvHPknXB1YYXyc/07rQaGR3PT2AxNeXyisoG1wrsLsCdzZiKgNcJh2gHovYeqOoap6ckv8AIEKzTXyVwrBhhzOEjZySOqKPwlavJIrDxUsKjqrBUFgpO0gbBfmhjab3W5pkUorZ7COq0tMnrhICrfwVvn+0d8QahcK9JyESqGUQGFiLgWvYbNufkiVRaPUsCflWO4eCv2xvwcz3FujtFO1ssosFPo3CNkOJFOBlbsiZLpgd1rwsrwioaelWlL+2PY0ETdcZGBR+0PY0EKIs+kdT/mFF5tI92kZpoxlq5s8FSHlS5YXO4wM7Xv04/VGGp/zCi82ke7SG8XMTVd+Ze0/ZBd+Ze0/ZG2CANV35l7T9kF35l7T9kbYIA1XfmXtP2QXfmXtP2RtggDVd+Ze0/ZBd+Ze0/ZG2CANV35l7T9kF35l7T9kbYIA1XfmXtP2QXfmXtP2RtggDVifmXtP2QYn5l7T9kRNJaWEsWGbc3N0mEFRpac30iP2cvXFJSSLxg5FU4SaHumt4uaGwy5ahbbATyiT1xUX0bKkgyp8mXMlm9pgQXHltmLDeIuWmtDGYSxuzHeWN8umKvpCna6WDq6XIzaYrdDKcz5RcjmMUU0zTtyiRdH6O7lzkkGXcG5bYpOV3GWG+x7W3GxhnUPgmJNwkKxEuYDbYckfLI2YjPpiLo1iclFjmyW5UsN9JMW5W3qbEcwiZUUSsmFwVDDlIp2E9MaIqe1MmxjCXTTLE2sADmSPZv5+qNrTwtibCwsOoWHsjyTpEXvfqiBwXvRdMsmSoWxFr4ucnMt1xzzhM0gWlcWubTGw+u/8ACJtJrM8pWkk5LmpP5jZqOrZ1QvKrPmLMfwUuR0k9EcMnUj0scE037lU1So6iRWUj4bAzFS+f0iRn0ZmLVwgU6zJs0XyliQo8pdsgfIYx03VJLVSHCFSCrE2sQdsVzSOvTOWAXjQxQsxGHOXe2Dy74v6pu0iXogqbNOlKWQJqSZbYjblqc1vuGLn6Ilyacy7XXaPCGy/SBshNoLRxLYzfEST2xdaWVlHStlRwTlbtI1UtM3QOke2J8pAvSeeIk2fhuu4WYeQm3qJ9cbUfKJM2VnXcEoDb6Y/ytHkb9dE+QX/iL/lf7I9iSD6F1P8AmFF5tI92kN4Uan/MKLzaR7tIbxczCCCCACCCCACCCCACCCCACCCCACNNXUiWjMdwjdFd1hqiXWXuAuf66orJ0rLRVuhepaYxZjtziSKYAXMFNa1zYdMJtKa70Us4GnYmzylqz7OlRaOa7Ot7bInT7bB64q+nESxuCNljzEbxzQ6k10uYgmoxKkb1IPWDsjnusGn509mEviJUtTYzJhzJ/rdaKqLZdyomaO0gXuv0lyY725mJ3kwweVgBLbeaKlq5UOs+7MrclswLBh/2MWOqqMUdEeKOaS32E+kKs3MRJFbYxhpR7XhUk/OBdIbaxVWGUk4C5QlWGzJtnrv2xWDrZUNbDhHNlf2xYhVo0tkmHJhY9Ytfq2xTaeyTCh2gkQUU92Rqa8ktKabPcNNYsen+Aiy0ur4w7B/XRGjRbDKLJStEsiyFQ6NwQ2krG1ADGdoEEGvTIE7M1bnwttHq7QIjUk3aMsjbKJ1QpIOz/wAZ/wAIU0rWII8Ell+rYr/yMo6oENETXH8Qv/EX/LMgjVrY/wAiv/EHsmQRJU+iNT/mFF5tI92kN4Uan/MKLzaR7tIbxczCCCCACCCCACCCCACCCCACCCCAI2ktIJIlTJsw2SWpZj0DmG8nZ1xQ9FV06oxzZieEz2IZWUKLALcbCM8vth5wiOO5kUnJp0rF0hG4wr03wWhZQYjLliWyqgVsa2uSLckDPLbc9cYZW+DpwJNskzKdZkoq+ak3YZ5gbsorGlqKo5HEy5EhA2fJVppG4g7Fi20RHqjHS6y5aGY27dvJOQHbGG5vSIFIjvSGXNILMpBPSRutHJ6PRGF2lsFLKx8LM7TZgLx12bWGWoxAGwJYXOX6KhRY+XojmWtrsanjVTApCEc9xe/tjSNoidPcgz6cSXuOSDtPSdvrhgKvLtiLpar42QjsAM8+Y2F8vqwpl1eIReBSaR7paqGcV6dXc0SdKV6DInEfzR/HdCGfVYtgsPXGiRk5JEv/ANQzzMRqipxOGG3n540IhOzOJlLo5rgmJpGdtj3RM05RaqJ9kJNG0NgMosFLIirLDKSY3mNUhY3QLGphCgyQFmS+kzFO84Lkj6hb6sOmtzQs0rNw4XIyUi/kG0fVxwIsrGtE+8hel1PYr/bBGjWRMMsp+ZNw9gbP2QRJU+mNT/mFF5tI92kN4Uan/MKLzaR7tIbxczCCCCACCCCACCCCACCCCACCMZkwKCTsGZPMBHL9M8KFUj4pcgcRnZsLM5A2Ne4HVaIbolKyx8J8g9xiYL/IzEc/snkseoNfqip6L00qSprXJIQ2A3ndaPJuvU6rknip6EOpBUykZTfapG7LKKVU6Sm0qEPJJVd6E7M8yG2Z9MUmlI0x3F2dXoaobbixF73sPXEfSFfLqMBluk0SHuwVgVBIKjEwyyN8oV6BoDOQvjIp3QsQcjY58l/orbbeEentEzzTzZVCVlyULTLl+XMxMzcmwyPhZnIgC0ctNbNnb/LeiyS9L8ZMeXxb4EyLS2DMx/NXZbrMUrXKRLIPFpMF7hnd7ta4soW5z3E7umHupFSkuQsmbMCTAobDiF2VxcOrHwgYg61PJlqZha43AsLX3xZNJktbVRWa2eeIKW8HG5G+wTPsAikVWlGa4GQ9f/aGtVrNdjgBINw99hUixUDpBOcKe4jcb75jMEkbjtjoiqVnHOduiOkgnZEyRoy5zhjQ0UP6XReyLWRSFtBoQc0O5OhgAMomU1HhhnJl5RWwQaaitu2QwlSbRmsrbG1RAbGKrAWj1oxw5wDMTOA3wk07Xji2sCfZmCP4w5NGp2mItfopDLdQCSykDywRUpes98KEjNlkMfKZVifrAwRt1sQ8XTk75YHUjTQPbBFgfSup/wAwovNpHu0hvCjU/wCYUXm0j3aQ3ixmEEEEAEEEEAEEEEAER6yvSULu4UdJ9g2mN5jmGuPGPVzFLELkMtoWwyHNe+ZgBjrBryZyTJVKBYgo01mK2vkQoCm5t2RU6PRzISWfFcWwm5C8+Em1weYqIYSKUKBYWAHJXmHP5Y3NLvbCL+zrivJZbFfp9XpSzMa3XI4jiwLYZ4mUc3PD/VWZJqJU2fhunGFUxC+JJdhjI/Sa58kIeEClcUE0qxBDIZgX/wBsmzD2Hqir6P14aRSKktOQOTibJSeYWzYxnkTpJHRhatuTOx6fnKlFPGXKlMNmXLFrW3ix2RQNBz5lLo6peobGzLxcpDbGoIIQdNy+Q6Ir0jXPSFUi8iW0sEZEEXw7iQbndDebo+qqQHnTBLtmqyltZtxLG5yO6MtEmzdZIRWwv4SdFsJdMLANT06BiLfo5AjMi5aKJS6Omzdocrz5ke2LbP1QdzypztuN2LXt5TzwxotD8UAAY2itKowm9TtCSi1WVVzxXPOsZzdXbC46ujp6IsoQ3zjY8sdkWszoq66OZTcE23DbDPR1Q+NFZMiwBN7WB3wyMiMRJOVjY559Fje3qiCRhS4XF12XI+qbRLWTCXV2vExZgAsVc3XmxAW9Sw8R4FWzUVzjLDGUyMWgQYPGlo2PsjVigSjB0J2Rom07WzcjyRumOd0RZxO9rQQKjrI5NNTm98M2ol59Dlh6ngjTrBOvSfs1Tj60tWv1wRcg+ntT/mFF5tI92kN4Uan/ADCi82ke7SG8SZhBBBABBBBABBBBABFA1vlWqybZlFNycuY5b90X+KrrzoZ5qpMlDE8u912YlO4Hnv7YEoqZmDfnEWv0sJY5TLLHSQIrGmdYpiXUypyNzlMI6nYgdkUvSemHxZBAx2G/GOSeYnZFbL0W3TGvKKpwqZl7i7AhSDlaxzYGOe1pdwGK4VXJVGxbnd1mL5onUc4VadczGFyTc2vu6IZay6qqKOYFAxWuOrOJJ2o91V0ZhkJ6uuLEq2hdqNVcbRym3qMDeVSYczEteIoiyvTB7THkoA57hGufMyyjLQrpMqJcqYWCvcEqM72JFtu+Ktl0nZJ4sWuRGlpUM63Qc1GAU4kPgllIbfttcbo1Po6YQMLSzf8AauOgjdGfcj7m3Zn7EBTESsrOLRiou2xRzsxFvYYw0hPmyWImIR+kMwemE1Fp5nntLSWrPiBR5hISWqqbuQNubHfuEXW/BjK4umM9ELMlTFM0j5RgpFrZkgAk7znFmEUDTelpTVEsS2edxIQqEyDzr3ZjkbKMrW23i26PrnYIJoCzGUtYAgXv4Iub3sR5bGJoqT5hyjXijya2XZ7Y1loFj2Y8aXaB22xGaZeBVmUyZEOeyjMtGUx4jzp6jdc3ggVTTDA08y17d0j3WUEeaRe8qcD4wp/wzBFyD6m1P+YUXm0j3aQ3jjOhOGviaanldyYuLlS0xcfa+BFW9uKyvbniZ+Hn9S/eP5USZnWoI5L+Hn9S/eP5UH4ef1L94/lQB1qCOS/h5/Uv3j+VB+Hn9S/eP5UAdagjkv4ef1L94/lQfh5/Uv3j+VAHWo8ZARYxyb8PP6l+8fyoPw8/qX7x/KgDoOldV5M9SrorA7mAI7DHNtIcGcmlq+OC3VjdUOxWHN0b7RI/D1+pfvH8qEmsHDDxzJelsFGQ4++Z3/i4EofvttGGk5eKWR0X7BFK/CaMV+5z/fD7uMn4T/1c8344fdwZayZwZvZamUfozbjri21Y5LdAMcr0JrqJFRNdZJIbavGW38+Dp5od1PCeGVh3MRcH/fX/APziEHyTpi5eS0RtXah0r5BlhSWYpyycIDixPJzBtCl9eBhtxG3+1/0QrbWrlAqjKQRZhMsR0g4cjGbWxrF0z6CSVMBPGFDllZCvPvJN4rFU6hyN4Ym4y6M4rVNwrpLyWkbmN6t3v9dDCbTPCIZkxmEnDls4y/8A0COVwZ3RypeS+mSk9XJyFsIJ9ov0xzuroFxvLa112dKnMRjo3XtsT4pZZQQQvGWtl0qcoX6w61ibMSYsoowGE/KAgjIj6A2XMbYk06Ms8oyjZIoQZFwlwp2hSUcdIcZnyHKM9I6XqJeAy5gmS3ORmAYwwzKO4355c8KH1iuPxeY34/8ATEd9NXlzUKZTBfwvBZSLMMtucbnEdGpaovKRmtcjlW2XGREeu0U3R+t+GWimVeyi54y1znnbDG5td8/xJ/vB8ERRNloZo0WiuNrt/Y/4n+iPF1z/ALL/ABP9MKILCZF9sApQd1+mESa4DfJJ/wDst/0RtbXUW/En+9/0QLEPT1EqSph3mel/7t4Ig6X0+JqOOLteYreHfYrC3g9MeRJFH//Z
I wrote this test that keeps on adding 'a' to parameter until the browser fails
C# part:
[AcceptVerbs(HttpVerbs.Get)]
public ActionResult ParamTest(string x)
{
ViewBag.TestLength = 0;
if (!string.IsNullOrEmpty(x))
{
System.IO.File.WriteAllLines("c:/result.txt",
new[] {Request.UserAgent, x.Length.ToString()});
ViewBag.TestLength = x.Length + 1;
}
return View();
}
View:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
<script type="text/javascript">
$(function() {
var text = "a";
for (var i = 0; i < parseInt(#ViewBag.TestLength)-1; i++) {
text += "a";
}
document.location.href = "http://localhost:50766/Home/ParamTest?x=" + text;
});
</script>
PART 1
On Chrome I got:
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36
2046
It then blew up with:
HTTP Error 404.15 - Not Found The request filtering module is
configured to deny a request where the query string is too long.
Same on Internet Explorer 8 and Firefox
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E)
2046
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
2046
PART 2
I went easy mode and added additional limits to IISExpress applicationhost.config and web.config setting maxQueryStringLength="32768".
Chrome failed with message 'Bad Request - Request Too Long
HTTP Error 400. The size of the request headers is too long.
after 7744 characters.
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36
7744
PART 3
Added
<headerLimits>
<add header="Content-type" sizeLimit="32768" />
</headerLimits>
which didn't help at all. I finally decided to use fiddler to remove the referrer from header.
static function OnBeforeRequest(oSession: Session) {
if (oSession.url.Contains("localhost:50766")) {
oSession.RequestHeaders.Remove("Referer");
}
Which did nicely.
Chrome: got to 15613 characters. (I guess it's a 16K limit for IIS)
And it failed again with:
<BODY><h2>Bad Request - Request Too Long</h2>
<hr><p>HTTP Error 400. The size of the request headers is too long.</p>
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.130 Safari/537.36
15613
Firefox:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
15708
Internet Explorer 8 failed with iexplore.exe crashing.
After 2505
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E)
2505
Android Emulator
Mozilla/5.0 (Linux; Android 5.1; Android SDK built for x86 Build/LKY45) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/39.0.0.0 Mobile Safari/537.36
7377
Internet Explorer 11
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C)
4043
Internet Explorer 10
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C)
4043
Internet Explorer 9
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
4043
WWW FAQs: What is the maximum length of a URL? has its own answer based on empirical testing and research. The short answer is that going over 2048 characters makes Internet Explorer unhappy and thus this is the limit you should use. See the page for a long answer.
On Apple platforms (iOS/macOS/tvOS/watchOS), the limit may be a 2 GB long URL scheme, as seen by this comment in the source code of Swift:
// Make sure the URL string isn't too long.
// We're limiting it to 2GB for backwards compatibility with 32-bit executables using NS/CFURL
if ( (urlStringLength > 0) && (urlStringLength <= INT_MAX) )
{
...
On iOS, I've tested and confirmed that even a 300+ MB long URL is accepted. You can try such a long URL like this in Objective-C:
NSString *path = [#"a:" stringByPaddingToLength:314572800 withString:#"a" startingAtIndex:0];
NSString *js = [NSString stringWithFormat:#"window.location.href = \"%#\";", path];
[self.webView stringByEvaluatingJavaScriptFromString:js];
And catch if it succeed with:
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType
{
NSLog(#"length: %#", #(request.URL.absoluteString.length));
return YES;
}
There is really no universal maximum URL length. The max length is determined only by what the client browser chooses to support, which varies widely. The 2,083 limit is only present in Internet Explorer (all versions up to 7.0). The max length in Firefox and Safari seems to be unlimited, although instability occurs with URLs reaching around 65,000 characters.
Opera seems to have no max URL length whatsoever, and doesn't suffer instability at extremely long lengths.
The URI RFC (of which URLs are a subset) doesn't define a maximum length, however, it does recommend that the hostname part of the URI (if applicable) not exceed 255 characters in length:
URI producers should use names that
conform to the DNS syntax, even when
use of DNS is not immediately
apparent, and should limit these names
to no more than 255 characters in
length.
As noted in other posts though, some browsers have a practical limitation on the length of a URL.
The HTTP 1.1 specification says:
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.
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.* 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).
Note: Servers ought to be cautious about depending on URI
lengths
above 255 bytes, because some older client or proxy
implementations might not properly support these lengths.
As mentioned by #Brian, the HTTP clients (e.g. browsers) may have their own limits, and HTTP servers will have different limits.
Microsoft Support says "Maximum URL length is 2,083 characters in Internet Explorer".
IE has problems with URLs longer than that. Firefox seems to work fine with >4k chars.
In URL as UI Jakob Nielsen recommends:
the social interface to the Web relies on email when users want to recommend Web pages to each other, and email is the second-most common way users get to new sites (search engines being the most common): make sure that all URLs on your site are less than 78 characters long so that they will not wrap across a line feed.
This is not the maximum but I'd consider this a practical maximum if you want your URL to be shared.
Sitemaps protocol, which is a way for webmasters to inform search engines about pages on their sites (also used by Google in Webmaster Tools), supports URLs with less than 2048 characters. So if you are planning to use this feature for Search Engine Optimization, take this into account.
ASP.NET 2 and SQL Server reporting services 2005 have a limit of 2028. I found this out the hard way, where my dynamic URL generator would not pass over some parameters to a report beyond that point. This was under Internet Explorer 8.
Why is the Internet Explorer limit only 2K while IIS has a limit of 16K? I don't think it makes sense.
So I want to start an experiment about Ajax request URL size limits.
I have set my Tomcat HTTP connector's maxHttpHeaderSize="1048576". And prepared a very long URL.
Then I send a request with the long URL like the following:
var url="/ajax/url-length.jsp";
jQuery.ajax(url,{data:{q:"0".repeat(1048000-url.length-4)}});
jQuery reports done. Tomcat reports the URL requested is 1048015 bytes. It was tested with Chrome 50 and Internet Explorer 11.
So web browsers won't truncate or limit your URL intentionally when sending Ajax requests.
Limit request line directive sets the maximum length of a URL. By default, it is set to 8190, which gives you a lot of room. However other servers and some browses, limit the length more.
Because all parameters are passed on the URL line, items that were in password of hidden fields will also be displayed in the URL of course. Neither mobile should be used for real security measures and should be considered cosmetic security at best.
It seems that Chrome at least has raised this limit. I pasted 20,000 characters into the bookmarklet and it took it.
I have experience with SharePoint 2007, 2010 and there is a limit of the length URL you can create from the server side in this case SharePoint, so it depends mostly on, 1) the client (browser, version, and OS) and 2) the server technology, IIS, Apache, etc.
According to the HTTP spec, there is no limit to a URL's length. Keep your URLs under 2048 characters; this will ensure the URLs work in all clients & server configurations. Also, search engines like URLs to remain under approximately 2000 characters.
As a result of my research, I discovered that the HTTP standard does not specify a maximum length for URLs. In fact, it is determined by the web browser and the server the request is made.
There are different limitations on the maximum length of URLs for different web browsers. The following are some common limits for popular web browsers:
Internet Explorer: 2,083 characters
Google Chrome: 8,192 characters
Mozilla Firefox: 65,536 characters
Safari: 80,000 characters
To ensure compatibility with as many web browsers and servers as possible, URLs should generally be short and simple. Request is better if you need to send large amounts of data. Instead of including data in the URL, the request body will include the data.
Related
I have strange problem, cause I don't know how to get background request
I have newly updated site "whitestudio.org", and trying to test in the mentioned above service. Hovewer, google return me 503 response message. Don't know what to do.
Also, tried to test from command line, tested with success. Can anyone help me?
curl -H "Mozilla/5.0 (compatible; GoogleBot/2.1; +http://www.google.com/bot.htm)" whitestudio.org
By the way pagespeed bot header for mobile is
Mozilla/5.0 (iPhone; CPU iPhone OS 8_3 like Mac OS X) AppleWebKit/537.36 (KHTML, like Gecko; Google Page Speed Insights) Version/8.0 Mobile/12F70 Safari/600.1.4
(Wrote for those who want to test in future).
And that error was related to incorrect configured "A" record [DNS configuration - We migrated from one host to another.
Our website is receiving http requests from a user which contains 'Coikoe' tag instead of 'Cookie'.
Http request object received from firefox is mentioned below :
com.pratilipi.servlet.UxModeFilter doFilter: REQUEST : GET http://www.pratilipi.com/books/gujarati HTTP/1.1
Host: http//www.pratilipi.com
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: http://www.pratilipi.com/?action=login
Coikoe: _gat=1; visit_count=1; page_count=2
X-AppEngine-Country: XX
X-AppEngine-Region: xx
X-AppEngine-City: XXXXXX
X-AppEngine-CityLatLong: 12.232344,12.232445
Http request object received from google chrome is mentioned below :
com.pratilipi.servlet.UxModeFilter doFilter: REQUEST : GET http//www.pratilipi.com/books/hindi HTTP/1.1
Host: http//www.pratilipi.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.132 Safari/537.36
Referer: http//www.pratilipi.com
Accept-Language: en-US,en;q=0.8,ta;q=0.6
Coikoe: _gat=1; visit_count=1; page_count=1
X-AppEngine-Country: XX
X-AppEngine-Region: xx
X-AppEngine-City: xxxxxx
X-AppEngine-CityLatLong: 12.232344,12.232445
User is using window 8 system.
Question : Why is this happening and how can I solve it? I have never seen anything like this before. Anyone has come accross anything like this
Thank You
This user will be using some sort of privacy proxy.
The same happens for the Connection request header as explained in Cneonction and nnCoection HTTP headers: the proxy mangles the header so it won't be recognized by the receiver, but by merely shuffling some letters around the TCP packet's checksum will remain the same.
I'm gonna give a rather speculative answer based on some online research.
I went through all the specifications for cookies right from the early drafts and there doesn't seem to be anything about coikoe or misspelling cookies.
I found another user (Pingu) who complained about the same on Twitter about the same. His relevant tweets:
(1) Weird problem: have a device that changes "Cookie" to "Coikoe" in TCP stream and don't know which it is. No deep packet inspection in place.
(2) There is a Linksys Wifi Router, a Cisco Switch adding a VLAN-Tag and a Linux box routing the VLAN to Internet router. Nothing else. #Coikoe
I then asked him about it earlier today. This was his replay:
It must have been something with my routing and iptables setup on the Linux box to allow the guests only limited access.
I can remember the problem. But do not remember how I solved it. It happened from Clients connected to my Guest WiFi.
Given my understanding from your discussion in the comments earlier, I'm guessing that the router sends a coikoe header instead of a cookie if the user has limited connectivity and/or problems with the access point.
Also see this ruby code to see how they have handled the different cookie header:
def set_cookie_header
request.headers["HTTP_COOKIE"] ||= request.headers["HTTP_COIKOE"]
end
I looked lots of other popular forums like reddit, 4chan, stackoverflow, facebook and google, but I could not get anything else. Goodluck with your problem.
Well this is something like a typo mistake, just to confirm , use the following powershell command in the project directory
Get-ChildItem -recurse | Select-String -pattern "Coikoe" | group path | select name
and i hope you will be able to find the mistake you have made.
Q:
I have a web application which published on a server .When i try the web application from another city. the performance is so bad and every thing is slow.
Should i make any enhancement to my code or this is related mostly to the network factors?
Any advices please.
Error/Status Code: 200
Start Offset: 0.194 s
Initial Connection: 193 ms
Time to First Byte: 286 ms
Content Download: 1286 ms
Bytes In (downloaded): 48.6 KB
Bytes Out (uploaded): 0.4 KB
Request Headers:
GET /sch/ScheduleForm.aspx HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1 PTST/25
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Response Headers:
HTTP/1.1 200 OK
Date: Wed, 21 Dec 2011 15:17:00 GMT
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Set-Cookie: ASP.NET_SessionId=ane2ncmyyoqwckjmv4bijq45; path=/; HttpOnly
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 4938
First of all you must find if the delay is because of the network, or by the server it self, or by the Client Computer or by your page design.
Its rare to have bad performance only because you change city, maybe the other computer have slow connection or bad configuration, or bad isp and you see that slow.
Client Quick Check
The faster way to a quick check of the network responce is to ping your site, open a command promt window and just write "ping www.yoursite.com /t" and see the time. And if your server is on the same country must be under 50ms.
Network - Page design
Now second point of a global check. You can use this site
http://www.webpagetest.org/
to check the speed of your page globally, and get very interesting results, as the time response.
Server
There always the case that you have place your site on a multi use/shared computer, with thousand of sites and bad configuration, so on peak time the server performs badly. I have see this happens a lot of times.
Your Web Application
If the site is slow compare with the development computer then is ether because live have a huge database that you do not have check, ether because a hacker have found a back door and is attacking by making empty accounts as attack, or something similar. This is up to you to find if the delay is because of your calls inside your program.
And more reasons for that delay exist
One more note, use the tools that exist on Chrome, Mozilla, Opera and Safari to see the time response of your site when your page load.
Hope this helps.
Your best starting point would be to find out where the speed issue is coming from. Try Firebug/Chrome debugging tools to see if the time is being taken on the server (ie sending you the first byte of the website) or if it's just plain old loading time (eg images take a long time).
If it's on the server then you have potentially some architectural/coding issues, if it's just delivery time of content then you have network/content issues (compress content with GZip, optimise pngs with PNGOUT that sort of thing).
Good luck :)
That depends heavily how the geographical location of the two cities is. If the two cities are nearby you will most likely not notice any difference.
If the cities are on different continents you may notice for sure latency issues.
If you have latency issues you can not solve them solely by adjusting your code. You need to do something like e.g. geographical load balancing and hosting different servers at different locations.
Facebook e.g. has multiple data centres.. e.g. one at the West-Coast one on the East-Coast and i think they have one in Europe as well. Depending from which location you come from requests are forwarded to the nearest data centre.
Say one is to write an HTTP server/client, how important is it to support HTTP/1.0? Is it still used anywhere nowdays?
Edit: I'm less concerned with the usefullness/importance of HTTP/1.0, rather the amount of software that actually uses it for non-internal (unit testing being internal use, for example) purposes in the real world (browsers, robots, smartphones/stupidphones, etc...).
As of 2016, you would think that the prominence would decline even more since 1.1 was introduced in 1999 so this is about 17 years.
I checked 7,727,198 lines of logs to see what percent I get of HTTP/1.0 and HTTP/1.1:
Protocol Counts Percent
--------------------------------
HTTP/0.9 0 0.00%
HTTP/1.0 1,636,187 21.17% (all)
HTTP/1.0 15,415 0.20% (without the obvious robots)
HTTP/1.1 6,091,011 78.83%
HTTP/2 0 0.00%
From what I can see, most of the HTTP/1.0 are from robots. So I tried to remove entries that were obviously from such (i.e. Agent including the word robot, bot, slurp, etc.)
So it looks like the amount of end users still stuck with HTTP/1.0 is very limited today (0.2%). However, if you want to let robots check out your websites, you may need/want to keep HTTP/1.0 operational. Most will anyway include the Host: ... header even though they advertise their connection as an HTTP/1.0 protocol.
Also, the differences between HTTP/1.0 and HTTP/1.1 is very blurry in terms of implementation. Most people are happily mixing both. I would not worry too much about still accepting/handling HTTP/1.0 requests.
On another server I am starting to see HTTP/2.0 requests that look like this (got 2427 and I see 34,161,268 HTTP/1.0 and HTTP/1.1 requests, so 0.007%):
PRI * HTTP/2.0
wget uses HTTP/1.0, and it is still relatively popular (though it does support a few HTTP/1.1 features like the Host: header, which is necessary to access any virtual hosts).
A fair number of servers will deliberately return HTTP/1.0 responses because some (older) browsers will afford a HTTP/1.0 server a higher connection limit than the 2-connection limit imposed for HTTP/1.1's persistent connections.
But in general, most "HTTP/1.0" implementations are really just slightly limited versions of the HTTP/1.1 implementations, and many HTTP/1.1 implementations don't really support some features of that version (e.g. pipelining in particular).
I use it all the time when I'm telnet-ing to a server to verify connectivity or figure out why it's not working:
$ telnet 192.168.1.1 80
GET / HTTP/1.0\r\n
\r\n
...
(Because making a 1.0 request doesn't require that I provide any extra headers).
HTTP/1.0 is very important in writing very basic clients that don't need the overhead of all the 1.1 things like pipelining and other complicated things required by 1.1. Post a request get a response and disconnect is very easy to code for. This might be useful in writing test cases for your server that just want to test the application functionality and NOT the HTTP protocol implementation.
There are lots of mobile browsers and applications that use 1.0 because they don't have the space or need for more sophisticated 1.1 implementations, and the latency issues with non-3G connections on non-smart phones completely negates any benefits of 1.1 features.
There are also lots of proxies that degrade everything to 1.0 regardless of what the client asks for, and then there is IE issues.
So the short answer is, for a general purpose HTTP server, 1.0 is very relevant.
Looking into this myself for other purposes:
"HTTP/1.0 is in use by proxies, some mobile clients, and IE when
configured to use a proxy. So 1.0 appears to still account for a non-
trivial % of traffic on the web overall.
...
Yes, there are many 1.0 clients still out there."
Source (July 2009): http://groups.google.com/group/erlang-programming/msg/08f6b72d5156ef74
:-(
Update (March 2011):
If you are going to build a client/server thingy, make the client use HTTP/1.1, and make the server accept both 1.1 and 1.0.
Doing web-development, it is a PITA to get clients trying to load a page without the Host header, because I have no way to know which site I am supposed to load :-S
So you better don't build a client like that ;-)
IME its been a very long time since I've seen a true HTTP/1.0 request. (including mobile devices fuzzylollipop).
I say a true request as MSIE still (pretends) to downgrade to HTTP/1.0 by default (unless yo sig in the config) when you connect via a proxy (all the outgoing requests are flagged as HTTP/1.0) - however it still includes HTTP/1.1 specific request headers and respects all the HTTP/1.1 responses.
Curiously, IIS, in a mirror image, happily ignores the HTTP version (although I've not experimented much with this to see if only does this for MSIE user agents).
So by curious coincidence, MSIE and IIS work much better with proxies than with standards-compliant tools.
C.
We're getting some odd errors reported on our website, and are trying to find out some details on who is doing the looking. I'm looking at a sample user-agent strings and seeing things like:
Mozilla/5.0 (Windows; U; Windows NT6.0; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6
Now some of this is obvious, but some of it is less so ("U"?) From the pattern of the hits, I'd suspect that this was a robot, but I don't see anything that I recognize in this string to clue me in to that. I'd like to know what some of the things in this (and other different) strings mean. Is there a comprehensive reference somewhere?
This Wikipedia page gives a good overview, and describes the meaning of the 'U' attribute as well.
User-agent strings (as all request headers) are not to be trusted at all, but I recommend www.useragentstring.com as a reference for helping you determine the patterns you're interested in.
The U stands for security as the Mozilla User Agent String Reference states. The link to wikipedia has been provided by somebody else already
In future I suggest you use these two sites
http://www.useragentstring.com/
http://www.browserscope.org/
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 Firefox/3.0.11
This is my current user agent.
Mozilla/5.0 - browser
Macintosh - platform
U - 256 bit encryption supported
Intel Mac OS X 10.5 - my operating system
en-US - language
rv:1.9.0.11 - revision
Gecko/2009060214 - rendering engine
Firefox/3.0.11 - browser version
Robots can fake User-Agent strings, so what it declares is irrelevant. It can simply be done with e.g. curl -A user-agent-here.