HTTPリクエストヘッダー

    NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:url] cachePolicy:NSURLRequestUseProtocolCachePolicy timeoutInterval:30.0];
    [request setHTTPMethod:@"POST"];
    [request setHTTPBody:bodyData];
    [request setValue:@"gzip, deflate" forHTTPHeaderField:@"Accept-Encoding"];
    [request setValue:@"application/x-www-form-urlencoded; charset=utf-8" forHTTPHeaderField:@"Content-Type"];
    [request setValue:[NSString stringWithFormat:@"%lu", (unsigned long)bodyData.length] forHTTPHeaderField:@"Content-Length"];
    [request setValue:authorization forHTTPHeaderField:@"Authorization"];

Yuantikku のネットワーク リクエスト (YTKNetwork) は、リクエスト メソッド、リクエスト本文、およびリクエスト ヘッダーをカプセル化しています。ユーザーが オーバーロード カスタマイズできるようにするためのリクエスト ヘッダーには以下が含まれます:

#pragma mark - Subclass Override
///=============================================================================
/// @name Subclass Override
///=============================================================================

///  Called on background thread after request succeded but before switching to main thread. Note if
///  cache is loaded, this method WILL be called on the main thread, just like `requestCompleteFilter`.
- (void)requestCompletePreprocessor;

///  Called on the main thread after request succeeded.
- (void)requestCompleteFilter;

///  Called on background thread after request succeded but before switching to main thread. See also
///  `requestCompletePreprocessor`.
- (void)requestFailedPreprocessor;

///  Called on the main thread when request failed.
- (void)requestFailedFilter;

///  The baseURL of request. This should only contain the host part of URL, e.g., http://www.example.com.
///  See also `requestUrl`
- (NSString *)baseUrl;

///  The URL path of request. This should only contain the path part of URL, e.g., /v1/user. See alse `baseUrl`.
///
///  @discussion This will be concated with `baseUrl` using [NSURL URLWithString:relativeToURL].
///              Because of this, it is recommended that the usage should stick to rules stated above.
///              Otherwise the result URL may not be correctly formed. See also `URLString:relativeToURL`
///              for more information.
///
///              Additionaly, if `requestUrl` itself is a valid URL, it will be used as the result URL and
///              `baseUrl` will be ignored.
- (NSString *)requestUrl;

///  Optional CDN URL for request.
- (NSString *)cdnUrl;

///  Requset timeout interval. Default is 60s.
///
///  @discussion When using `resumableDownloadPath`(NSURLSessionDownloadTask), the session seems to completely ignore
///              `timeoutInterval` property of `NSURLRequest`. One effective way to set timeout would be using
///              `timeoutIntervalForResource` of `NSURLSessionConfiguration`.
- (NSTimeInterval)requestTimeoutInterval;

///  Additional request argument.
- (nullable id)requestArgument;

///  Override this method to filter requests with certain arguments when caching.
- (id)cacheFileNameFilterForRequestArgument:(id)argument;

///  HTTP request method.
- (YTKRequestMethod)requestMethod;

///  Request serializer type.
- (YTKRequestSerializerType)requestSerializerType;

///  Response serializer type. See also `responseObject`.
- (YTKResponseSerializerType)responseSerializerType;

///  Username and password used for HTTP authorization. Should be formed as @[@"Username", @"Password"].
- (nullable NSArray<NSString *> *)requestAuthorizationHeaderFieldArray;

///  Additional HTTP request header field.
- (nullable NSDictionary<NSString *, NSString *> *)requestHeaderFieldValueDictionary;

///  Use this to build custom request. If this method return non-nil value, `requestUrl`, `requestTimeoutInterval`,
///  `requestArgument`, `allowsCellularAccess`, `requestMethod` and `requestSerializerType` will all be ignored.
- (nullable NSURLRequest *)buildCustomUrlRequest;

///  Should use CDN when sending request.
- (BOOL)useCDN;

///  Whether the request is allowed to use the cellular radio (if present). Default is YES.
- (BOOL)allowsCellularAccess;

///  The validator will be used to test if `responseJSONObject` is correctly formed.
- (nullable id)jsonValidator;

///  This validator will be used to test if `responseStatusCode` is valid.
- (BOOL)statusCodeValidator;

リクエスト ヘッダーは、NSURLSessionTask の構築に使用する

書き換えメソッドを通じてネットワーク リクエストをシリアル化します

- (NSDictionary *)requestHeaderFieldValueDictionary {
    NSString *paraUrlString = AFQueryStringFromParameters([self requestArgument]);
    NSString *authorization =[[YTKNetworkConfig sharedConfig] getAuthorization:[self requestUrl]];
    return @{@"Accept-Encoding":@"gzip, deflate",
             @"Content-Type":@"application/x-www-form-urlencoded; charset=utf-8",
             @"Content-Length":[NSString stringWithFormat:@"%lu", (unsigned long)paraUrlString.length],
             @"Authorization":authorization};
}

以下は、リクエストヘッダー: Accept-Encoding

- (NSDictionary *)requestHeaderFieldValueDictionary；返回一个字典，然后在方法
- (AFHTTPRequestSerializer *)requestSerializerForRequest:(YTKBaseRequest *)request； は、ローカルがデータを圧縮形式で受信でき、サーバーが大きなファイルを圧縮して、クライアントが受信を完了した後に解凍することを意味します。データをローカルに保存します。

gzip: UNIX システム ファイル圧縮、HTTP プロトコルの gzip エンコーディングは、トラフィックの多い WEB サイトで高速な処理を実現するためによく使用されます。これは通常、WWW サーバーにインストールされる

の機能を指します。誰かがこのサーバーの Web サイトにアクセスすると、サーバー内のこの機能は、Web ページのコンテンツを圧縮して、訪問先のコンピューターのブラウザーに送信して表示します。テキストコンテンツは元のサイズの 40% に圧縮されるため、当然、サーバーの負荷も増加します。

• 。 : LZ77 アルゴリズムとハフマンコーディングを使用する方式。可逆データ圧縮のための特許を取得していない圧縮技術です。

• HTTP コンテンツのエンコーディングと HTTP 圧縮の違い: HTTP プロトコルでは、コンテンツ (つまり、ボディ部分) ) をエンコードでき、gzip などのエンコーディングを使用して、コンテンツをスクランブルまたは暗号化して、不正な第三者がドキュメントのコンテンツを閲覧できないようにすることもできます。これは、実際には HTTP コンテンツ エンコーディングの一種です。 1. クライアントは、HTTP リクエストを Web サーバーに送信します。 リクエストには、gzip、deflate が含まれます (ブラウザが gzip 圧縮をサポートしていることをサーバーに伝えます)。 2. サーバーはリクエストを受信すると、元の Content-Type と Content-Length を含むレスポンスを生成します。

  3. サーバーは、gzip を介してレスポンスをエンコードします。 -Length (圧縮サイズ)、Content-Encoding:gzip を増加させて、クライアントに応答を送信します。
4. レスポンスを受信した後、クライアントは Content-Encoding:gzip に従ってレスポンスをデコードします。 元の応答を取得した後、データの表示が処理されます。
• その他

  : compress はエンティティが Unix ファイル圧縮プログラムを使用することを示し、identity はエンティティがエンコードされていないことを示します。これは、Content-Encoding ヘッダーがない場合のデフォルトのケースです。 Gzip、圧縮、およびデフレート エンコーディングはすべて可逆圧縮アルゴリズムであり、情報の損失を引き起こすことなく送信メッセージのサイズを削減するために使用されます。 その中で、通常は gzip が最も効率的で、最も広く使用されています。

• Content-Type
  
  
  
  はコンテンツタイプを表します。これは通常、クライアント上に存在するContent-Typeを指し、ネットワークファイルのタイプとWebページのエンコーディングを定義するために使用され、どのような形式かを決定します。クライアントがこのファイルを読み取ることになります。つまり、クライアントはこのパラメータに基づいて、送受信されるデータの種類を識別するために使用されます。

• application/x-www-form-urlencoded: データは、標準のエンコード形式である名前と値のペアとしてエンコードされます。multipart/form-data: フォーム データは、ページ上のそれぞれの としてメッセージとしてエンコードされます。コントロールはメッセージの一部に相当します。 text/plain: フォーム データは、コントロールや書式設定文字を含まないプレーン テキストとしてエンコードされます。
  1. action が get の場合、ブラウザは x-www-form-urlencoded エンコーディング メソッドを使用してフォーム データを文字列 (name1=value1&name2=value2...) に変換し、この文字列を末尾に追加します。 URL を ? で分割して、この新しい URL をロードします。
  2. アクションがポストされると、ブラウザはフォーム データを http 本文にカプセル化し、サーバーに送信します。 type=file コントロールがない場合は、デフォルトの application/x-www-form-urlencoded を使用してください。 ただし、type=file がある場合は、multipart/form-data が使用されます。ブラウザはフォーム全体をコントロールユニットに分割し、それぞれにContent-Disposition(form-data or file)、Content-Type(デフォルトはtext/plain)、name(コントロール名)などを追加します。情報と区切り文字 (境界) を追加します。

Content-Length

• は、HTTPメッセージエンティティの送信長を表します。メッセージ エンティティの長さ: Entity-length、圧縮前のメッセージ本文の長さ。
  メッセージ エンティティの送信長: Content-length、圧縮後のメッセージ本文の長さ。 (パラメータをつなぎ合わせた辞書)

Authorization

• HTTP 基本認証は、Web ブラウザーまたは他のクライアント プログラムが、認証時にユーザー名とパスワードの形式で資格情報を提供できるようにするために使用されるログイン方法です。リクエストです。 認証メカニズムは、サーバーによって設定されたルールに従って決定されます。

• 認証と承認の違い: 飛行機に乗りたい場合は、ID カードと航空券を提示する必要があります。ID カードは、Zhang San が本当に本人であることを証明するものです。航空券は、張三さんが本当に航空券を購入し、飛行機に搭乗できることを証明するものです。 フォーラムにログインし、ユーザー名 Zhang San、パスワード 1234 を入力する必要があります。パスワードが正しいことは、Zhang San が確かに Zhang San であることを証明し、これが認証であり、ユーザー Zhang San がモデレーターであることを確認します。したがって、彼は他の人の投稿を追加および削除する権限を持っています。

POST と GET の違い

• HTML の観点から見ると:
  1. ブラウザがロールバックしても GET は無害ですが、POST はリクエストを再度送信します。
  2. GET で生成された URL アドレスはブックマークできますが、POST ではブックマークできません。
  3. GET リクエストはブラウザによってアクティブにキャッシュされますが、POST は手動で設定しない限りキャッシュされません。
  4. GET リクエストは URL エンコードのみ可能ですが、POST は複数のエンコード方法をサポートします。
  5. GETリクエストパラメータはブラウザ履歴に完全に保持されますが、POSTのパラメータは保持されません。
  6. GET リクエストの URL で送信されるパラメーターには長さの制限がありますが、POST には長さの制限がありません。
  7. パラメーターのデータ型に関しては、GET は ASCII 文字のみを受け入れますが、POST には制限がありません。
  8. GET は、パラメーターが URL 上で直接公開されるため、機密情報の転送には使用できないため、POST よりも安全ではありません。 9. GET パラメーターは URL 経由で渡され、POST はリクエスト本文に配置されます。
  

HTTP の観点から:
• 1. HTTP は、World Wide Web でのデータ通信方法に関する

  TCP/IP
  に基づくプロトコルです。 HTTP の最下層は TCP/IP です。したがって、GET と POST の最下層も TCP/IP です。つまり、GET/POST は両方とも TCP リンクです。 GET と POST は同じことを実行できます。リクエスト本文を GET に追加し、URL パラメーターを POST に追加する必要があります。技術的には、これは完全に実現可能です。 HTTP は単なる動作ルールであり、TCP は GET と POST の実装方法の基礎です。 2. メソッドが POST データの場合、BODY に配置する必要はありません。メソッドが GET の場合、データ (パラメーター) は BODY ではなく URL に配置する必要はありません。つまり、GET と POST はデータの配信方法とは何の関係もありません。 HTTP プロトコルには、GET と POST の両方に長さの制限はありません。セキュリティと不安は GET と POST とは何の関係もありません。 3. GET は 1 つの TCP データ パケットを生成し、POST は 2 つの TCP データ パケットを生成します。 GET リクエストの場合、ブラウザーは http ヘッダーとデータを一緒に送信し、サーバーは 200 (データを返す) で応答します。POST の場合、ブラウザーは最初にヘッダーを送信し、サーバーは 100
  Continue
  で応答します。ブラウザはデータを送信し、サーバーは 200 ok (データを返す) で応答します。

HTTP ステータス コード包括的

1、1** 情報、サーバーはリクエストを受信し、リクエスターは操作の実行を続行する必要があります
2、2** 成功、操作は正常に受信され、処理されました
3、3** 繰り返し指示、リクエストを完了するにはさらにアクションが必要です
4、4** クライアント エラー、リクエストに 構文エラーが含まれているか、リクエストを完了できません 5、5** サーバー エラー、エラーサーバーがリクエストを処理中に発生しました

以上がHTTPリクエストヘッダーの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。