HTTP 요청 헤더

클라이언트는 서버API인터페이스의 경우 HTTP 요청 헤더를 구성해야 합니다. 일반적으로 NSMutableURLRequest를 초기화한 후 요청 메서드, 요청 본문, 요청 헤더를 다음과 같이 설정합니다.

    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"];

YuanTiKu의 네트워크 요청(

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；
메서드에서 네트워크 요청을 직렬화합니다. 필드의 의미: - (AFHTTPRequestSerializer *)requestSerializerForRequest:(YTKBaseRequest *)request；

Accept-Encoding

은 로컬이 압축 형식으로 데이터를 받을 수 있고 서버가 압축한다는 의미입니다. 클라이언트가 수신을 완료한 후 로컬에서 데이터 압축을 푼다.

• gzip: UNIX 시스템에서 파일 압축에 사용됩니다. HTTP 프로토콜은 웹 애플리케이션 성능 향상을 위해 사용됩니다. 트래픽이 많은 웹 사이트에서는 사용자가 더 빠른 속도를 경험할 수 있도록 하는 경우가 많습니다. 이는 일반적으로 누군가가 이 서버에 있는 웹 사이트를 방문할 때 설치되는 기능을 의미합니다. , 서버 이 기능은 웹 페이지 콘텐츠를 압축하여 방문 컴퓨터 브라우저에 전송하여 표시합니다. 일반적으로 일반 텍스트 콘텐츠를 원래 크기의 40%로 압축할 수 있으므로 데이터 전송 속도가 빨라집니다. 또한, 이 기능 모듈은 일반 서버에 설치됩니다.
• deflate: LZ77 알고리즘과 허프만 코딩 기술을 사용하여 무손실 데이터 압축. 🎜>

  HTTP 콘텐츠 인코딩과 HTTP 압축의 차이점: HTTP 프로토콜에서는 콘텐츠(즉, 본문 부분)를 인코딩할 수 있으며 gzip과 같은 인코딩을 사용하여 달성할 수 있습니다. 목적. 인증되지 않은 제3자가 문서의 내용을 볼 수 없도록 다른 인코딩을 사용하여 내용을 암호화할 수도 있습니다. >HTTP 압축 프로세스:

  1. 클라이언트가 웹 서버에 HTTP 요청을 보냅니다. 요청에는 Accept-Encoding: gzip, deflate(브라우저가 gzip 압축을 지원한다고 서버에 알립니다)가 포함되어 있습니다.
2. 요청을 받은 후 서버는 원본 Content-Type 및 Content-Length를 포함하는 원본 응답을 생성합니다.
• 3. 서버는 gzip을 통해 Response를 인코딩합니다. 인코딩 후 헤더에는 Content-Type 및 Content-Length(압축 크기)가 포함되고 Content-Encoding: gzip이 추가되어 클라이언트에 전송됩니다.

  4. 클라이언트는 응답을 받은 후 Content-Encoding:gzip에 따라 응답을 디코딩합니다. 원래 응답을 얻은 후 데이터 표시가 처리됩니다.

• 기타
: 압축은 엔터티가 Unix 파일 압축 프로그램을 사용함을 나타냅니다. ID는 엔터티가 인코딩되지 않았음을 나타냅니다. Content-Encoding 헤더가 없는 경우 기본적으로 그렇습니다. Gzip, 압축 및 수축 인코딩은 모두 정보 손실 없이 전송된 메시지의 크기를 줄이는 데 사용되는 무손실 압축 알고리즘입니다. 그 중에서 일반적으로 gzip이 가장 효율적이고 가장 널리 사용됩니다.

• 
  
  Content-Type
  
  

은 콘텐츠 유형을 나타내며, 일반적으로 클라이언트에 존재하는 Content-Type을 의미하며, 유형 및 웹 페이지의 인코딩에 따라 클라이언트가 파일을 읽는 형식과 인코딩이 결정됩니다. 즉, 클라이언트는 이 매개변수를 기반으로 데이터를 어떻게 열 것인지 결정하는 데 사용됩니다.

• 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-Dis위치(양식 데이터 또는 파일), Content-Type(기본값은 text/plain), 이름(컨트롤 이름) 및 기타 정보를 추가합니다. , 구분 기호(경계)를 추가합니다.

Content-Length

• 는 HTTP 메시지 엔터티의 전송 길이를 나타냅니다. 메시지 엔터티 길이: 엔터티 길이, 압축 전 메시지 본문의 길이
  메시지 엔터티의 전송 길이: 콘텐츠 길이, 압축 후 메시지 본문의 길이. (함께 엮인 매개변수 사전)

인증

• HTTP 기본 인증은 웹 브라우저나 기타 클라이언트 프로그램을 허용하기 위해 사용하는 방식이다. 요청 시 사용자 이름과 비밀번호 형식으로 자격 증명을 제공하여 로그인하세요. 인증 메커니즘은 서버가 설정한 규칙에 따라 결정됩니다.

• 인증과 승인의 차이점: 비행기에 탑승하려면 신분증과 항공권을 제시해야 장산이 본인임을 증명할 수 있습니다. Zhang San, 이것은 인증이며 티켓은 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에 요청 본문을 추가하고 POST에 URL 매개변수를 추가해야 합니다. HTTP는 단지 동작 지침인 반면, TCP는 GET 및 POST가 구현되는 방식의 기초입니다.
  2. HTTP에 대한 요구 사항은 없습니다. 메소드가 POST 데이터인 경우 BODY에 배치되어야 합니다. 요구사항은 없습니다. 메소드가 GET인 경우 데이터(매개변수)는 BODY가 아닌 URL에 배치되어야 합니다. 즉, GET 및 POST는 데이터 전달 방법과 관련이 없습니다. HTTP 프로토콜에는 GET 및 POST 모두에 대한 길이 제한이 없습니다. 보안과 불안정성은 GET 및 POST와 관련이 없습니다.
  3. GET은 하나의 TCP 데이터 패킷을 생성하고 POST는 두 개의 TCP 데이터 패킷을 생성합니다. GET 요청의 경우 브라우저는 http 헤더와 데이터를 함께 보내고 서버는 200(데이터 반환)으로 응답합니다. POST의 경우 브라우저는 헤더를 먼저 보내고 서버는 continue, 브라우저는 데이터를 다시 보내고 서버는 200 ok(데이터 반환)로 응답합니다.

HTTP 상태 코드백과사전

1, 1** 정보, 서버가 요청을 받았고 요청자는 계속 작업을 수행해야 합니다
2, 2* * 성공, 작업이 성공적으로 수신되어 처리되었습니다.
3, 3** 리디렉션, 요청을 완료하려면 추가 작업이 필요합니다.
4, 4** 클라이언트 오류, 요청에 구문 오류 또는 요청을 완료할 수 없습니다5, 5** 서버 오류, 서버가 요청을 처리하는 동안 오류가 발생했습니다

위 내용은 HTTP 요청 헤더의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!