What is the maximum length URL?
URL的最大长度是多少?
This is may be handset dependent; on a desktop, it is definitely browser dependent, as discussed in this question.
这可能取决于手机;在桌面上,它肯定是依赖浏览器的,正如这个问题所讨论的那样。
I am interested in specifications or references as much as empirical data.
我对规范或参考资料和经验数据感兴趣。
My particular usecase is passing a very long (about 1600 character) URL to a MIDlet.platformRequest(String url), which is failing. The majority of the URL (some 1575 characters) is query.
我的特殊用例是将一个非常长(大约1600个字符)的URL传递给MIDlet.platformRequest(String url),这是失败的。大多数URL(大约1575个字符)是查询。
Are there any other considerations for passing very long URLs about (e.g. mobile proxies and gateways truncating the URL)?
传递很长的URL是否有任何其他考虑因素(例如,移动代理和网关截断URL)?
4 个解决方案
#1
According to the HTTP spec, you can rely on at least 255 characters, but beyond that it is browser specific. For example, IE limits the path part of the URL to 2048 characters, according to various sources, and Apache apparently complains about URLs > ~4000 characters.
根据HTTP规范,您可以依赖至少255个字符,但除此之外,它是特定于浏览器的。例如,根据各种消息来源,IE将URL的路径部分限制为2048个字符,而Apache显然会抱怨URL> ~4000个字符。
Source: WWW FAQs: What is the maximum length of a URL?
来源:WWW常见问题解答:URL的最大长度是多少?
I could not find any references to a URL limits for J2ME browsers.
我找不到任何对J2ME浏览器的URL限制的引用。
UPDATE: "In the field of mobile browsing, URL limitation can be much lower. Many handsets still don’t support URLs longer than 128, 256 or 512 characters, in particular WAP devices (as opposed to devices carrying a full blown HTTP browser)."
更新:“在移动浏览领域,URL限制可以低很多。许多手机仍然不支持长度超过128,256或512个字符的URL,特别是WAP设备(与携带完整HTTP浏览器的设备相对) “。
Source: Maximum URL Length Web Analytics
来源:最大URL长度Web分析
#2
As @Stephen C pointed out, you can only count on the first 255 characters making it through. Can you modify your application to use a POST method instead? There is no limit to the amount of data that can be sent in a POST transaction.
正如@Stephen C指出的那样,你只能依靠前255个字符来完成它。您可以修改您的应用程序以使用POST方法吗? POST事务中可以发送的数据量没有限制。
#3
Short answer: it depends, but probably long enough.
简短回答:这取决于,但可能足够长。
Long answer, following investigation on SonyEricsson J2ME emulator (WTK 2.2.4), a K610i, and Samsung U700V.
在对SonyEricsson J2ME仿真器(WTK 2.2.4),K610i和三星U700V进行调查后,答案很长。
Empirically testing: from the emulator, the platformRequest() passes the URL straight to the desktop browser (Firefox in this case).
经验测试:从模拟器中,platformRequest()将URL直接传递给桌面浏览器(在本例中为Firefox)。
http://test.example.com/?q=2048xxxxxxxxxxxxxxxxxxxxxxxxxxxx... xxxxxxxxxxxxxxxxxx2048
Looking at the logs of a test server, we see we can pass through very long URLs from the emulator to the desktop to the server.
查看测试服务器的日志,我们看到我们可以将非常长的URL从模拟器传递到桌面到服务器。
On a device (in this case, a SonyEricsson K610i, user agent: "SonyEricssonK610i/R1CB Browser/NetFront/3.3 Profile/MIDP-2.0 Configuration/CLDC-1.1") can handle at least a URL of at least 3072 characters (upper bound c.3800).
在设备上(在这种情况下,SonyEricsson K610i,用户代理:“SonyEricssonK610i / R1CB Browser / NetFront / 3.3 Profile / MIDP-2.0 Configuration / CLDC-1.1”)可以处理至少3072个字符的URL(上限) c.3800)。
On a second device Samsung U700V, user agent: "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7 MG(Novarra-Vision/7.3)", the lower bound for URL length was 2048, but upper bound was less than 3072. Note that this could be a problem with Novarra transcoder, which has been known to (at least) re-write user-agent strings.
在第二台设备Samsung U700V上,用户代理:“Mozilla / 5.0(X11; U; Linux i686; en-US; rv:1.8.0.7)Gecko / 20060909 Firefox / 1.5.0.7 MG(Novarra-Vision / 7.3)”, URL长度的下限是2048,但上限小于3072.请注意,这可能是Novarra代码转换器的问题,已知(至少)重写用户代理字符串。
Without the Novarra transcode (switching networks), the U700V has a user agent "SAMSUNG-SGH-U700-Vodafone/BUGK1 SHP/VPP/R5 NetFront/3.4 Qtv5.3 SMM-MMS/1.2.0 profile/MIDP-2.0 configuration/CLDC-1.1", and has a lower bound of 3072 chars.
没有Novarra转码(交换网络),U700V有一个用户代理“SAMSUNG-SGH-U700-Vodafone / BUGK1 SHP / VPP / R5 NetFront / 3.4 Qtv5.3 SMM-MMS / 1.2.0 profile / MIDP-2.0配置/ CLDC-1.1“,下限为3072个字符。
This effectively ends my interest in the answer to this question, as this empirical testing invalidates my theory that an upper bound on URL length is causing my problem.
这有效地结束了我对这个问题的答案的兴趣,因为这个经验测试使我的理论无效,即URL长度的上限导致了我的问题。
However, for completeness, I will include a potential cause of my problem:
但是,为了完整起见,我将列出我的问题的潜在原因:
The URL needed to connect has at least two query parameters. The ampersands separating the queries seem to confuse the emulator.
连接所需的URL至少有两个查询参数。分隔查询的&符似乎混淆了模拟器。
The emulator silently drops the second parameter.
模拟器静默地删除第二个参数。
On the Samsung, without a second parameter, the browser connects, but the long parameter is corrupted or missing.
在没有第二个参数的三星上,浏览器连接,但long参数已损坏或丢失。
On the K610i when a second parameter is used, the browser does not start properly.
在K610i上使用第二个参数时,浏览器无法正常启动。
#4
Microsoft Internet Explorer (Browser) Microsoft states that the maximum length of a URL in Internet Explorer is 2,083 characters, with no more than 2,048 characters in the path portion of the URL. In my tests, attempts to use URLs longer than this produced a clear error message in Internet Explorer. Firefox (Browser) After 65,536 characters, the location bar no longer displays the URL in Windows Firefox 1.5.x. However, longer URLs will work. I stopped testing after 100,000 characters. Safari (Browser) At least 80,000 characters will work. I stopped testing after 80,000 characters. Opera (Browser) At least 190,000 characters will work. I stopped testing after 190,000 characters. Opera 9 for Windows continued to display a fully editable, copyable and pasteable URL in the location bar even at 190,000 characters. Apache (Server) My early attempts to measure the maximum URL length in web browsers bumped into a server URL length limit of approximately 4,000 characters, after which Apache produces a "413 Entity Too Large" error. I used the current up to date Apache build found in Red Hat Enterprise Linux 4. The official Apache documentation only mentions an 8,192-byte limit on an individual field in a request. Microsoft Internet Information Server The default limit is 16,384 characters (yes, Microsoft's web server accepts longer URLs than Microsoft's web browser). This is configurable. Perl HTTP::Daemon (Server) Up to 8,000 bytes will work. Those constructing web application servers with Perl's HTTP::Daemon module will encounter a 16,384 byte limit on the combined size of all HTTP request headers. This does not include POST-method form data, file uploads, etc., but it does include the URL. In practice this resulted in a 413 error when a URL was significantly longer than 8,000 characters. This limitation can be easily removed. Look for all occurrences of 16x1024 in Daemon.pm and replace them with a larger value. Of course, this does increase your exposure to denial of service attacks. Recommendations Extremely long URLs are usually a mistake. URLs over 2,000 characters will not work in the most popular web browser. Don't use them if you intend your site to work for the majority of Internet users .
Microsoft Internet Explorer(浏览器)Microsoft声明Internet Explorer中URL的最大长度为2,083个字符,URL的路径部分中不超过2,048个字符。在我的测试中,尝试使用比此更长的URL会在Internet Explorer中生成明确的错误消息。 Firefox(浏览器)65,536个字符后,位置栏不再显示Windows Firefox 1.5.x中的URL。但是,较长的网址可以使用。我在100,000个字符后停止测试。 Safari(浏览器)至少80,000个字符可以使用。我在80,000个字符后停止测试。 Opera(浏览器)至少可以使用190,000个字符。我在190,000个字符后停止测试。 Opera 9 for Windows继续在位置栏中显示完全可编辑,可复制和可粘贴的URL,即使是190,000个字符。 Apache(服务器)我早期尝试测量Web浏览器中的最大URL长度会导致服务器URL长度限制大约为4,000个字符,之后Apache会产生“413 Entity Too Large”错误。我使用了当前最新的Red Hat Enterprise Linux 4中的Apache构建。官方Apache文档仅提到请求中单个字段的8,192字节限制。 Microsoft Internet Information Server默认限制为16,384个字符(是的,Microsoft的Web服务器接受的URL比Microsoft的Web浏览器长)。这是可配置的。 Perl HTTP ::守护进程(服务器)最多8,000个字节。那些使用Perl的HTTP :: Daemon模块构建Web应用程序服务器的人将在所有HTTP请求头的组合大小上遇到16,384字节的限制。这不包括POST方法表单数据,文件上载等,但它确实包含URL。实际上,当URL明显长于8,000个字符时,这会导致413错误。可以轻松删除此限制。在Daemon.pm中查找所有出现的16x1024,并用更大的值替换它们。当然,这确实会增加您遭受拒绝服务攻击的风险。建议极长的URL通常是错误的。超过2,000个字符的网址在最受欢迎的网络浏览器中无效。如果您希望您的网站为大多数互联网用户工作,请不要使用它们。
When you wish to submit a form containing many fields, which would otherwise produce a very long URL, the standard solution is to use the POST method rather than the GET method:
当您希望提交包含许多字段的表单时,否则会生成一个非常长的URL,标准解决方案是使用POST方法而不是GET方法:
...The form fields are then transmitted as part of the HTTP transaction body, not as part of the URL, and are not subject to the URL length limit. Short-lived information should not be stored in URLs.
然后,表单字段作为HTTP事务正文的一部分传输,而不是作为URL的一部分传输,并且不受URL长度限制的约束。短期信息不应存储在URL中。
As a rule of thumb, if a piece of information isn't needed to regenerate the same page as a result of returning to a favorite or bookmark, then it doesn't belong in the URL. The Bookmark Problem In very rare cases, it may be useful to keep a large amount of "state" information in a URL. For instance, users of a map-navigating website might wish to add the currently displayed map to their "bookmarks" or "favorites" list and return later. If you must do this and your URLs are approaching 2,000 characters in length, keep your representation of the information as compact as you can, squeezing out as much "air" as possible. If your field names take up too much space, use a fixed field order instead. Squeeze out any field that doesn't really need to be bookmarked. And avoid large decimal numbers - use only as much accuracy as you must, and consider a base-64 representation using letters and digits (I didn't say this was easy).
根据经验,如果由于返回收藏夹或书签而不需要重新生成同一页面的信息,则它不属于URL。书签问题在极少数情况下,在URL中保留大量“状态”信息可能很有用。例如,地图导航网站的用户可能希望将当前显示的地图添加到他们的“书签”或“收藏夹”列表中并稍后返回。如果您必须这样做并且您的网址长度接近2,000个字符,请尽可能紧凑地表达您的信息,尽可能多地挤出“空气”。如果您的字段名称占用太多空间,请使用固定字段顺序。挤出任何不需要加入书签的字段。并避免使用大的十进制数 - 只使用尽可能多的精度,并考虑使用字母和数字的base-64表示(我没有说这很容易)。
In extreme cases, consider using the gzip algorithm to compress your pretty but excessively long URL. Then reencode that binary data in base64 using only characters that are legal in URLs. This can yield a 3-4x space gain, at the cost of some CPU time when you unzip the URL again on the next visit. Again, I never said it was easy!
在极端情况下,请考虑使用gzip算法来压缩漂亮但过长的URL。然后仅使用URL中合法的字符对base64中的二进制数据进行重新编码。这可以产生3-4倍的空间增益,当您在下次访问时再次解压缩URL时会花费一些CPU时间。再一次,我从未说过这很容易!
An alternative is to store the state information in a file or a database. Then you can store only the identifier needed to look up that information again in the URL. The disadvantage here is that you will have many state files or database records. Some of which might be linked to on websites run by others. One solution to this problem is to delete the state files or database records for the URLs that have not been revisited after a certain amount of time.
另一种方法是将状态信息存储在文件或数据库中。然后,您只能存储在URL中再次查找该信息所需的标识符。这里的缺点是你将拥有许多状态文件或数据库记录。其中一些可能与其他人运营的网站相关联。此问题的一个解决方案是删除在一定时间后未重新访问的URL的状态文件或数据库记录。
#1
According to the HTTP spec, you can rely on at least 255 characters, but beyond that it is browser specific. For example, IE limits the path part of the URL to 2048 characters, according to various sources, and Apache apparently complains about URLs > ~4000 characters.
根据HTTP规范,您可以依赖至少255个字符,但除此之外,它是特定于浏览器的。例如,根据各种消息来源,IE将URL的路径部分限制为2048个字符,而Apache显然会抱怨URL> ~4000个字符。
Source: WWW FAQs: What is the maximum length of a URL?
来源:WWW常见问题解答:URL的最大长度是多少?
I could not find any references to a URL limits for J2ME browsers.
我找不到任何对J2ME浏览器的URL限制的引用。
UPDATE: "In the field of mobile browsing, URL limitation can be much lower. Many handsets still don’t support URLs longer than 128, 256 or 512 characters, in particular WAP devices (as opposed to devices carrying a full blown HTTP browser)."
更新:“在移动浏览领域,URL限制可以低很多。许多手机仍然不支持长度超过128,256或512个字符的URL,特别是WAP设备(与携带完整HTTP浏览器的设备相对) “。
Source: Maximum URL Length Web Analytics
来源:最大URL长度Web分析
#2
As @Stephen C pointed out, you can only count on the first 255 characters making it through. Can you modify your application to use a POST method instead? There is no limit to the amount of data that can be sent in a POST transaction.
正如@Stephen C指出的那样,你只能依靠前255个字符来完成它。您可以修改您的应用程序以使用POST方法吗? POST事务中可以发送的数据量没有限制。
#3
Short answer: it depends, but probably long enough.
简短回答:这取决于,但可能足够长。
Long answer, following investigation on SonyEricsson J2ME emulator (WTK 2.2.4), a K610i, and Samsung U700V.
在对SonyEricsson J2ME仿真器(WTK 2.2.4),K610i和三星U700V进行调查后,答案很长。
Empirically testing: from the emulator, the platformRequest() passes the URL straight to the desktop browser (Firefox in this case).
经验测试:从模拟器中,platformRequest()将URL直接传递给桌面浏览器(在本例中为Firefox)。
http://test.example.com/?q=2048xxxxxxxxxxxxxxxxxxxxxxxxxxxx... xxxxxxxxxxxxxxxxxx2048
Looking at the logs of a test server, we see we can pass through very long URLs from the emulator to the desktop to the server.
查看测试服务器的日志,我们看到我们可以将非常长的URL从模拟器传递到桌面到服务器。
On a device (in this case, a SonyEricsson K610i, user agent: "SonyEricssonK610i/R1CB Browser/NetFront/3.3 Profile/MIDP-2.0 Configuration/CLDC-1.1") can handle at least a URL of at least 3072 characters (upper bound c.3800).
在设备上(在这种情况下,SonyEricsson K610i,用户代理:“SonyEricssonK610i / R1CB Browser / NetFront / 3.3 Profile / MIDP-2.0 Configuration / CLDC-1.1”)可以处理至少3072个字符的URL(上限) c.3800)。
On a second device Samsung U700V, user agent: "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7 MG(Novarra-Vision/7.3)", the lower bound for URL length was 2048, but upper bound was less than 3072. Note that this could be a problem with Novarra transcoder, which has been known to (at least) re-write user-agent strings.
在第二台设备Samsung U700V上,用户代理:“Mozilla / 5.0(X11; U; Linux i686; en-US; rv:1.8.0.7)Gecko / 20060909 Firefox / 1.5.0.7 MG(Novarra-Vision / 7.3)”, URL长度的下限是2048,但上限小于3072.请注意,这可能是Novarra代码转换器的问题,已知(至少)重写用户代理字符串。
Without the Novarra transcode (switching networks), the U700V has a user agent "SAMSUNG-SGH-U700-Vodafone/BUGK1 SHP/VPP/R5 NetFront/3.4 Qtv5.3 SMM-MMS/1.2.0 profile/MIDP-2.0 configuration/CLDC-1.1", and has a lower bound of 3072 chars.
没有Novarra转码(交换网络),U700V有一个用户代理“SAMSUNG-SGH-U700-Vodafone / BUGK1 SHP / VPP / R5 NetFront / 3.4 Qtv5.3 SMM-MMS / 1.2.0 profile / MIDP-2.0配置/ CLDC-1.1“,下限为3072个字符。
This effectively ends my interest in the answer to this question, as this empirical testing invalidates my theory that an upper bound on URL length is causing my problem.
这有效地结束了我对这个问题的答案的兴趣,因为这个经验测试使我的理论无效,即URL长度的上限导致了我的问题。
However, for completeness, I will include a potential cause of my problem:
但是,为了完整起见,我将列出我的问题的潜在原因:
The URL needed to connect has at least two query parameters. The ampersands separating the queries seem to confuse the emulator.
连接所需的URL至少有两个查询参数。分隔查询的&符似乎混淆了模拟器。
The emulator silently drops the second parameter.
模拟器静默地删除第二个参数。
On the Samsung, without a second parameter, the browser connects, but the long parameter is corrupted or missing.
在没有第二个参数的三星上,浏览器连接,但long参数已损坏或丢失。
On the K610i when a second parameter is used, the browser does not start properly.
在K610i上使用第二个参数时,浏览器无法正常启动。
#4
Microsoft Internet Explorer (Browser) Microsoft states that the maximum length of a URL in Internet Explorer is 2,083 characters, with no more than 2,048 characters in the path portion of the URL. In my tests, attempts to use URLs longer than this produced a clear error message in Internet Explorer. Firefox (Browser) After 65,536 characters, the location bar no longer displays the URL in Windows Firefox 1.5.x. However, longer URLs will work. I stopped testing after 100,000 characters. Safari (Browser) At least 80,000 characters will work. I stopped testing after 80,000 characters. Opera (Browser) At least 190,000 characters will work. I stopped testing after 190,000 characters. Opera 9 for Windows continued to display a fully editable, copyable and pasteable URL in the location bar even at 190,000 characters. Apache (Server) My early attempts to measure the maximum URL length in web browsers bumped into a server URL length limit of approximately 4,000 characters, after which Apache produces a "413 Entity Too Large" error. I used the current up to date Apache build found in Red Hat Enterprise Linux 4. The official Apache documentation only mentions an 8,192-byte limit on an individual field in a request. Microsoft Internet Information Server The default limit is 16,384 characters (yes, Microsoft's web server accepts longer URLs than Microsoft's web browser). This is configurable. Perl HTTP::Daemon (Server) Up to 8,000 bytes will work. Those constructing web application servers with Perl's HTTP::Daemon module will encounter a 16,384 byte limit on the combined size of all HTTP request headers. This does not include POST-method form data, file uploads, etc., but it does include the URL. In practice this resulted in a 413 error when a URL was significantly longer than 8,000 characters. This limitation can be easily removed. Look for all occurrences of 16x1024 in Daemon.pm and replace them with a larger value. Of course, this does increase your exposure to denial of service attacks. Recommendations Extremely long URLs are usually a mistake. URLs over 2,000 characters will not work in the most popular web browser. Don't use them if you intend your site to work for the majority of Internet users .
Microsoft Internet Explorer(浏览器)Microsoft声明Internet Explorer中URL的最大长度为2,083个字符,URL的路径部分中不超过2,048个字符。在我的测试中,尝试使用比此更长的URL会在Internet Explorer中生成明确的错误消息。 Firefox(浏览器)65,536个字符后,位置栏不再显示Windows Firefox 1.5.x中的URL。但是,较长的网址可以使用。我在100,000个字符后停止测试。 Safari(浏览器)至少80,000个字符可以使用。我在80,000个字符后停止测试。 Opera(浏览器)至少可以使用190,000个字符。我在190,000个字符后停止测试。 Opera 9 for Windows继续在位置栏中显示完全可编辑,可复制和可粘贴的URL,即使是190,000个字符。 Apache(服务器)我早期尝试测量Web浏览器中的最大URL长度会导致服务器URL长度限制大约为4,000个字符,之后Apache会产生“413 Entity Too Large”错误。我使用了当前最新的Red Hat Enterprise Linux 4中的Apache构建。官方Apache文档仅提到请求中单个字段的8,192字节限制。 Microsoft Internet Information Server默认限制为16,384个字符(是的,Microsoft的Web服务器接受的URL比Microsoft的Web浏览器长)。这是可配置的。 Perl HTTP ::守护进程(服务器)最多8,000个字节。那些使用Perl的HTTP :: Daemon模块构建Web应用程序服务器的人将在所有HTTP请求头的组合大小上遇到16,384字节的限制。这不包括POST方法表单数据,文件上载等,但它确实包含URL。实际上,当URL明显长于8,000个字符时,这会导致413错误。可以轻松删除此限制。在Daemon.pm中查找所有出现的16x1024,并用更大的值替换它们。当然,这确实会增加您遭受拒绝服务攻击的风险。建议极长的URL通常是错误的。超过2,000个字符的网址在最受欢迎的网络浏览器中无效。如果您希望您的网站为大多数互联网用户工作,请不要使用它们。
When you wish to submit a form containing many fields, which would otherwise produce a very long URL, the standard solution is to use the POST method rather than the GET method:
当您希望提交包含许多字段的表单时,否则会生成一个非常长的URL,标准解决方案是使用POST方法而不是GET方法:
...The form fields are then transmitted as part of the HTTP transaction body, not as part of the URL, and are not subject to the URL length limit. Short-lived information should not be stored in URLs.
然后,表单字段作为HTTP事务正文的一部分传输,而不是作为URL的一部分传输,并且不受URL长度限制的约束。短期信息不应存储在URL中。
As a rule of thumb, if a piece of information isn't needed to regenerate the same page as a result of returning to a favorite or bookmark, then it doesn't belong in the URL. The Bookmark Problem In very rare cases, it may be useful to keep a large amount of "state" information in a URL. For instance, users of a map-navigating website might wish to add the currently displayed map to their "bookmarks" or "favorites" list and return later. If you must do this and your URLs are approaching 2,000 characters in length, keep your representation of the information as compact as you can, squeezing out as much "air" as possible. If your field names take up too much space, use a fixed field order instead. Squeeze out any field that doesn't really need to be bookmarked. And avoid large decimal numbers - use only as much accuracy as you must, and consider a base-64 representation using letters and digits (I didn't say this was easy).
根据经验,如果由于返回收藏夹或书签而不需要重新生成同一页面的信息,则它不属于URL。书签问题在极少数情况下,在URL中保留大量“状态”信息可能很有用。例如,地图导航网站的用户可能希望将当前显示的地图添加到他们的“书签”或“收藏夹”列表中并稍后返回。如果您必须这样做并且您的网址长度接近2,000个字符,请尽可能紧凑地表达您的信息,尽可能多地挤出“空气”。如果您的字段名称占用太多空间,请使用固定字段顺序。挤出任何不需要加入书签的字段。并避免使用大的十进制数 - 只使用尽可能多的精度,并考虑使用字母和数字的base-64表示(我没有说这很容易)。
In extreme cases, consider using the gzip algorithm to compress your pretty but excessively long URL. Then reencode that binary data in base64 using only characters that are legal in URLs. This can yield a 3-4x space gain, at the cost of some CPU time when you unzip the URL again on the next visit. Again, I never said it was easy!
在极端情况下,请考虑使用gzip算法来压缩漂亮但过长的URL。然后仅使用URL中合法的字符对base64中的二进制数据进行重新编码。这可以产生3-4倍的空间增益,当您在下次访问时再次解压缩URL时会花费一些CPU时间。再一次,我从未说过这很容易!
An alternative is to store the state information in a file or a database. Then you can store only the identifier needed to look up that information again in the URL. The disadvantage here is that you will have many state files or database records. Some of which might be linked to on websites run by others. One solution to this problem is to delete the state files or database records for the URLs that have not been revisited after a certain amount of time.
另一种方法是将状态信息存储在文件或数据库中。然后,您只能存储在URL中再次查找该信息所需的标识符。这里的缺点是你将拥有许多状态文件或数据库记录。其中一些可能与其他人运营的网站相关联。此问题的一个解决方案是删除在一定时间后未重新访问的URL的状态文件或数据库记录。