虚拟主机 URL 长度限制？
我正在设计一个与我的 iPhone 应用程序绑定的 Web 应用程序。 它将大量 URL 发送到 Web 服务器（大约 15000 个）。我使用近乎自由语音.net，但它们仅支持最多 2000 个字符的 URL。 我想知道是否有人知道支持非常大的 URL 的网络托管？ 谢谢，艾萨克
编辑：我的程序需要在 Safari 中打开一张图片。 我可以通过两种方式执行此操作：
- 发送以 URL 形式编码的 Base64 并仅回显查询参数。
- 首先将其发布到我的应用程序中的服务器，然后服务器将照片存储在数据库中后发回一个唯一的 ID，我将其附加到一个 URL，我将在 Safari 中打开该 URL，该 URL 从数据库中检索照片并将其删除从数据库中。
你看，我很懒，而且我知道 Mobile Safari 可以支持最多 80 000 个字符的 URI，所以我认为这是一个不错的方法。 如果这确实有什么问题，请告诉我。
编辑：我最终以正确的 POST 方式完成了它。 谢谢。
I am designing a web application which is a tie in to my iPhone application. It sends massively large URLs to the web server (15000 about.) I was using NearlyFreeSpeech.net, but they only support URLS up to 2000 characters. I was wondering if anybody knows of web hosting that will support really large URLs? Thanks, Isaac
Edit: My program needs to open a picture in Safari. I could do this 2 ways:
- send it base64 encoded in the URL and just echo the query parameters.
- first POST it to the server in my application, then the server would send back a unique ID after storing the photo in a database, which I would append to a URL which I would open in Safari which retrieved the photo from the database and delete it from the database.
You see, I am lazy, and I know Mobile Safari can support URI's up to 80 000 characters, so I think this is a OK way to do it. If there is something really wrong with this, please tell me.
Edit: I ended up doing it the proper POST way. Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您要发送 15,000 个字符长的网址，很可能是：
alt text http://img16 .imageshack.us/img16/3847/youredoingitwronga.jpg
使用类似 HTTP POST 的内容。
您遇到的限制与其说是主机的问题，不如说是 Web 服务器对 URL 长度的限制。 根据 此页面，Apache 将您限制在 4k 字符左右，而 IIS 则限制您默认为 16k。
If you're sending 15,000 character long URLs, in all likelyhood:
alt text http://img16.imageshack.us/img16/3847/youredoingitwronga.jpg
Use something like an HTTP POST instead.
The limitations you're running up against aren't so much an issue with the hosts - it's more the fact that web servers have a limit for the length of a URL. According to this page, Apache limits you to around 4k characters, and IIS limits you to 16k by default.
虽然它没有直接回答您的问题，并且没有正式的 URL 最大长度，但浏览器和服务器有实际限制 - 请参阅 http://www.boutell.com/newfaq/misc/urllength.html 了解一些详细信息。 简而言之，由于 IE（至少在使用的某些版本）不支持超过 2,083 个字符的 URL，因此保持低于该长度可能是明智的。
Although it's not directly answering your question, and there is no official maximum length of a URL, browsers and servers have practical limits - see http://www.boutell.com/newfaq/misc/urllength.html for some details. In short, since IE (at least some versions in use) doesn't support URLs over 2,083 characters, it's probably wise to stay below that length.
如果您只需要在 Safari 中打开它，并且不需要涉及服务器，为什么不使用
数据：URI？通过网络发送长 URI 基本上从来都不是正确的做法。 正如您所注意到的，某些 Web 主机不支持长 URI。 某些代理服务器也可能会因长 URL 而阻塞，这意味着您的应用程序可能无法为这些代理背后的用户运行。 如果您需要将应用程序移植到其他浏览器，其他浏览器可能不支持那么长时间的 URI。
如果您需要将数据发送到服务器，请使用 POST。 是的，虽然多了一个往返，但会可靠很多。
另外，如果您使用 GET 请求将数据上传到服务器，那么您很容易受到各种 交叉攻击- 站点请求伪造攻击； 基本上，攻击者可以通过让用户点击链接（可能被 TinyURL 或其他 URL 缩短服务，或者只是在用户没有仔细查看所点击的 URL 时作为链接嵌入到网页中）。
除了不会实际更改服务器上任何内容的查询参数之外，您永远不应该使用 GET 向服务器发送数据。
If you need to just open it in Safari, and the server doesn't need to be involved, why not use a
data:URI?Sending long URIs over the network is basically never the right thing to do. As you noticed, some web hosts don't support long URIs. Some proxy servers may also choke on long URLs, which means that your app might not work for users who are behind those proxies. If you ever need to port your app to a different browser, other browsers may not support URIs that long.
If you need to get data up to a server, use a POST. Yes, it's an extra round trip, but it will be much more reliable.
Also, if you are uploading data to the server using a GET request, then you are vulnerable to all kinds of cross-site request forgery attacks; basically, an attacker can trick the user into uploading, say, goatse to their account simply by getting them to click on a link (perhaps hidden by TinyURL or another URL shortening service, or just embedded as a link in a web page when they don't look closely at the URL they're clicking on).
You should never use GET for sending data to the server, beyond query parameters that don't actually change anything on the server.