关于URL最大长度限制的相关资料查证,url查证
关于URL最大长度限制的相关资料查证,url查证
在开发调试支付宝接口时,突然发现支付宝接口的URL很长,远远大于之前自己印象中的255个字符。赶紧搜索查证了一番,理解如下:
URL不能大于255bytes的说法确实存在,在RFC2616中提到:
复制代码 代码如下:
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.
从上一点也可以看出,255bytes的说法也是为了兼容性考虑。实际上现代浏览器的限制如下:
复制代码 代码如下:
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 16×1024 in Daemon.pm and replace them with a larger value. Of course, this does increase your exposure to denial of service attacks.
另外值得注意的是,有文章提到作为的href属性时,URL不能超过1024bytes,这点没有详细查证
综上,URL还是不适合太长,不是不得已,尽量不要通过GET方式提交大量参数,可以考虑用POST方式(大约在2M左右,应该是和服务器及设定有关)。另外这么长的URL在访问和收藏(有文章提到有些浏览器在收藏超长地址时也是会出现问题)时也是相当不友好的。当然,之前数据库字段设置时还是作为255bytes处理,现在可能要考虑扩充一下了。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック









PHP 関数の紹介 - get_headers(): URL の応答ヘッダー情報の取得の概要: PHP 開発では、Web ページまたはリモート リソースの応答ヘッダー情報を取得する必要があることがよくあります。 PHP 関数 get_headers() を使用すると、対象 URL の応答ヘッダー情報を簡単に取得し、配列の形式で返すことができます。この記事では、get_headers() 関数の使用法を紹介し、関連するコード例をいくつか示します。 get_headers() 関数の使用法: get_header

エラーの理由は、urllib3 ライブラリの例外タイプである NameResolutionError(self.host,self,e)frome です。このエラーの理由は、DNS 解決が失敗したこと、つまり、ホスト名または IP アドレスが試みられたことです。解決できるものが見つかりません。これは、入力された URL アドレスが間違っているか、DNS サーバーが一時的に利用できないことが原因である可能性があります。このエラーを解決する方法 このエラーを解決するにはいくつかの方法があります。 入力された URL アドレスが正しいかどうかを確認し、アクセス可能であることを確認します。 DNS サーバーが利用可能であることを確認します。コマンド ラインで「ping」コマンドを使用してみてください。 DNS サーバーが利用可能かどうかをテストします。プロキシの背後にある場合は、ホスト名の代わりに IP アドレスを使用して Web サイトにアクセスしてみてください。

現在、ゲームを愛する多くの Windows ユーザーが Steam クライアントにアクセスし、優れたゲームを検索、ダウンロードしてプレイすることができます。ただし、多くのユーザーのプロフィールがまったく同じ名前である可能性があるため、プロフィールを見つけたり、Steam プロフィールを他のサードパーティのアカウントにリンクしたり、Steam フォーラムに参加してコンテンツを共有したりすることさえ困難になります。プロファイルには一意の 17 桁の ID が割り当てられます。ID は変更されず、ユーザーがいつでも変更することはできませんが、ユーザー名またはカスタム URL は変更できます。いずれにせよ、一部のユーザーは自分の Steamid を知らないため、これを知ることが重要です。アカウントの Steamid を見つける方法がわからなくても、慌てる必要はありません。記事上で

相違点: 1. 定義が異なります。URL はユニフォーム リソース ロケーターであり、HTML はハイパーテキスト マークアップ言語です。 2. HTML には多数の URL を含めることができますが、URL 内に存在できる HTML ページは 1 つだけです。 3. HTML は is を指します。 Web ページ、url は Web サイトのアドレスを指します。

url を使用して、クラス java.net.URLDecoder.decode(url, decoding format) decoder.decoding メソッドのエンコードとデコードをエンコードおよびデコードします。通常の文字列に変換するには、URLEncoder.decode(url, エンコード形式) を使用して、通常の文字列を指定された形式の文字列に変換します。 packagecom.zixue.springbootmybatis.test;importjava.io.UnsupportedEncodingException;importjava.net.URLDecoder;importjava.net。 URLエンコーダ

Scrapy は、インターネットから大量のデータを取得するために使用できる強力な Python クローラー フレームワークです。ただし、Scrapy を開発する場合、重複した URL をクロールするという問題が頻繁に発生します。これは、多くの時間とリソースを無駄にし、効率に影響を与えます。この記事では、重複 URL のクロールを減らし、Scrapy クローラーの効率を向上させるための Scrapy 最適化テクニックをいくつか紹介します。 1. Scrapy クローラーの start_urls 属性と allowed_domains 属性を使用して、

場合によっては、サービス コントローラーのプレフィックスが一貫している場合があります。たとえば、すべての URL のプレフィックスは /context-path/api/v1 であり、一部の URL には統一されたプレフィックスを追加する必要があります。考えられる解決策は、サービスのコンテキスト パスを変更し、コンテキスト パスに api/v1 を追加することです。グローバル プレフィックスを変更すると、上記の問題を解決できますが、欠点もあります。URL に複数のプレフィックスがある場合、たとえば、 URL にはプレフィックスが必要です。api/v2 の場合は区別できません。サービス内の一部の静的リソースに api/v1 を追加したくない場合は、区別できません。以下では、カスタム アノテーションを使用して、特定の URL プレフィックスを均一に追加します。 1つ、

URLは「Uniform Resource Locator」の略で、中国語で「統一リソースロケーター」を意味します。 URL は、インターネット経由で特定のリソースを見つけてアクセスするために使用されるアドレスで、Web ブラウジングや HTTP リクエストでよく見られます。 URL の主な機能は、インターネット上のリソース (Web ページ、写真、ビデオ、ドキュメント、その他のファイル) を見つけてアクセスすることです。
