HTTP-Anfrageheader

Der Client verwendet die ServerAPISchnittstelle verwendet wird, müssen HTTP-Anforderungsheader erstellt werden. Im Allgemeinen wird ein NSMutableURLRequest initialisiert und dann werden die Anforderungsmethode , der Anforderungstext und die Anforderungsheader wie folgt festgelegt :

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

Yuantikus Netzwerkanfrage (

YTKNetwork) hat die Anfragemethode, den Anfragetext und den Anfrageheader gekapselt, sodass Benutzer zur Anpassung überladen können, einschließlich:

.>

#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;

Der Anforderungsheader gibt ein Wörterbuch zurück, indem er die Methode

überschreibt, und serialisiert dann die Netzwerkanforderung in der Methode - (NSDictionary *)requestHeaderFieldValueDictionary；
zur Verwendung bei der Erstellung von NSURLSessionTask 🎜>- (AFHTTPRequestSerializer *)requestSerializerForRequest:(YTKBaseRequest *)request；Im Folgenden wird detailliert auf die Bedeutung mehrerer Felder im Anforderungsheader eingegangen:

- (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

bedeutet, dass das Lokal Daten empfangen kann komprimiertes Format, und der Server komprimiert die große Datei während der Verarbeitung. Nachdem der Client den Empfang abgeschlossen hat, dekomprimiert er die Daten lokal Dateikomprimierung im UNIX-System, gzip-Kodierung im HTTP-Protokoll. Web-Sites mit hohem Datenverkehr nutzen häufig gzip, um Benutzern eine höhere Geschwindigkeit zu ermöglichen Wenn jemand auf eine Website zugreift, komprimiert diese Funktion im Server den Inhalt der Webseite und übermittelt ihn zur Anzeige im Allgemeinen auf 40 % der Originalgröße Die Datenübertragung wird dadurch erhöht. Im Allgemeinen wird dieses Funktionsmodul auf dem Server installiert. Komprimierungstechnologie ohne patentierten Algorithmus

• Der Unterschied zwischen HTTP-Inhaltskodierung und HTTP-Komprimierung: Im HTTP-Protokoll kann der Inhalt (d. h. der Körperteil) kodiert werden, und gzip kann es sein Codierung verwendet. Um den Zweck der Komprimierung zu erreichen, können Sie auch andere Codierungen verwenden, um zu verhindern, dass unbefugte Dritte den Inhalt des Dokuments sehen .

• HTTP-Komprimierungsprozess: 1 Der Client sendet eine HTTP-Anfrage an den Webserver und die Anfrage enthält Accept-Encoding: gzip, deflate (teilen Sie dem Server das mit der Browser unterstützt es.

  2. Nach Erhalt der Anfrage generiert der Server die ursprüngliche Antwort, die den ursprünglichen Inhaltstyp und die ursprüngliche Inhaltslänge enthält.
3. Der Server kodiert die Antwort durch gzip. Nach der Kodierung enthält der Header Content-Type und Content-Length (komprimierte Größe) und dann wird die Antwort an den Client gesendet.
• 4. Nach Erhalt der Antwort dekodiert der Client die Antwort gemäß Content-Encoding:gzip. Nach Erhalt der ursprünglichen Antwort wird die Anzeige der Daten verarbeitet.

• Andere

  : compress gibt an, dass die Entität ein Unix-Dateikomprimierungsprogramm verwendet. Die Identität zeigt an, dass die Entität nicht codiert ist. Dies ist standardmäßig der Fall, wenn kein Content-Encoding-Header vorhanden ist. Gzip-, Compress- und Deflate-Codierung sind allesamt verlustfreie Komprimierungsalgorithmen, die dazu dienen, die Größe übertragener Nachrichten zu reduzieren, ohne dass es zu Informationsverlusten kommt. Unter diesen ist gzip normalerweise das effizienteste und am weitesten verbreitete.

• 
  Content-Type
  
  
  

  stellt den Inhaltstyp dar und bezieht sich im Allgemeinen auf den auf dem Client vorhandenen Inhaltstyp, der zum Definieren des verwendet wird Typ und Kodierung der Webseite bestimmen die Form und Kodierung, in der der Client die Datei liest. Das heißt, es wird verwendet, um die Art der gesendeten oder empfangenen Daten zu identifizieren. Der Client bestimmt, wie die Daten basierend auf diesem Parameter geöffnet werden.

• application/x-www-form-urlencoded: Die Daten werden als Name/Wert-Paare codiert, was dem Standard-Codierungsformat entspricht./form-data: Die Formulardaten werden als Nachricht codiert , Jedes Steuerelement auf der Seite entspricht einem Teil der Nachricht. text/plain: Formulardaten werden als einfacher Text ohne Steuerelemente oder Formatierungszeichen codiert.
  1. Wenn action get ist, verwendet der Browser die Kodierungsmethode x-www-form-urlencoded, um die Formulardaten in eine Zeichenfolge (Name1=Wert1&Name2=Wert2...) umzuwandeln konvertiert dieses Wort. Hängen Sie die Zeichenfolge an das Ende der URL an, teilen Sie sie mit ? auf und laden Sie diese neue URL.
  2. Wenn die Aktion veröffentlicht wird, kapselt der Browser die Formulardaten in den HTTP-Text und sendet sie dann an den Server. Wenn kein type=file-Steuerelement vorhanden ist, verwenden Sie einfach die Standardanwendung/x-www-form-urlencoded. Wenn jedoch type=file vorhanden ist, werden multipart/form-data verwendet. Der Browser unterteilt das gesamte Formular in Steuereinheiten und fügt Content-DisPosition(Formulardaten oder Datei), Content-Type (Standard ist Text/Plain), Name( Steuerelementname) und andere Informationen hinzu und fügen Sie ein Trennzeichen (Grenze) hinzu.

Content-Length

• stellt die Übertragungslänge der HTTP-Nachrichtenentität dar. Länge der Nachrichtenentität: Entitätslänge, die Länge des Nachrichtentexts vor der Komprimierung;
  Übertragungslänge der Nachrichtenentität: Inhaltslänge, die Länge des Nachrichtentexts nach der Komprimierung. (Wörterbuch der zusammengefügten Parameter)

Autorisierung

• HTTP-Basisauthentifizierung ist eine Methode, die verwendet wird, um Webbrowser oder andere Client-Programme zuzulassen Melden Sie sich an, indem Sie auf Anfrage Anmeldeinformationen in Form von Benutzername und Passwort angeben. Autorisierungsmechanismus wird gemäß den vom Server festgelegten Regeln bestimmt.

• Der Unterschied zwischen Authentifizierung und Autorisierung: Wenn Sie an Bord des Flugzeugs gehen möchten, müssen Sie Ihren Personalausweis und Ihr Ticket vorzeigen. Der Personalausweis soll beweisen, dass Zhang San wirklich Sie ist. Zhang San, das ist eine Authentifizierung, und das Ticket soll beweisen, dass Sie das Ticket tatsächlich gekauft haben und in das Flugzeug einsteigen können, das ist eine Autorisierung. Sie müssen sich im Forum anmelden, den Benutzernamen Zhang San und das Passwort 1234 eingeben. Das Passwort ist korrekt, was beweist, dass Sie Zhang San tatsächlich Zhang San sind. Dies ist eine Authentifizierung. Überprüfen Sie dann, ob der Benutzer Zhang San ein Moderator ist. Daher hat er die Befugnis, Beiträge anderer Personen hinzuzufügen und zu löschen.

Der Unterschied zwischen POST und GET

• Aus HTML-Perspektive:
  1 POST sendet die Anfrage erneut.
  2. Die von GET generierte URL-Adresse kann mit einem Lesezeichen versehen werden, POST jedoch nicht.
  3. GET-Anfragen werden vom Browser aktiv zwischengespeichert, POST jedoch nicht, sofern sie nicht manuell festgelegt werden.
  4. GET-Anfragen können nur URL-codiert werden, während POST mehrere Codierungsmethoden unterstützt.
  5. GET -Anfrageparameter bleiben vollständig im Browserverlauf erhalten, während die Parameter im POST nicht erhalten bleiben.
  6. Die in der URL der GET-Anfrage übertragenen Parameter haben Längenbeschränkungen, für POST gibt es jedoch keine Längenbeschränkungen.
  7. Bezüglich des Datentyps des Parameters akzeptiert GET nur ASCII-Zeichen, während POST keine Einschränkungen hat.
  8. GET ist weniger sicher als POST, da die Parameter direkt auf der URL verfügbar sind und daher nicht zur Übertragung sensibler Informationen verwendet werden können.
  9. GET-Parameter werden über die URL übergeben und POST wird im Anforderungstext platziert.

• Aus Sicht von HTTP:
  1. HTTP ist ein auf TCP/IP basierendes Protokoll über die Art und Weise, wie Daten im World Wide Web kommunizieren. Die unterste Schicht von HTTP ist TCP/IP. Die unterste Ebene von GET und POST ist also ebenfalls TCP/IP, das heißt, GET/POST sind beide TCP-Verbindungen. GET und POST können dasselbe tun. Sie müssen einen Anforderungstext zu GET und URL-Parameter zu POST hinzufügen. Technisch gesehen ist dies völlig machbar. HTTP ist lediglich eine Verhaltens Richtlinie, während TCP die Grundlage dafür ist, wie GET und POST implementiert werden.
  2. Es besteht keine Anforderung für HTTP. Wenn es sich bei der Methode um POST-Daten handelt, müssen diese im BODY platziert werden. Es besteht keine Anforderung. Wenn die Methode GET ist, müssen die Daten (Parameter) in der URL und nicht im BODY platziert werden. Das heißt, GET und POST haben nichts damit zu tun, wie die Daten übermittelt werden. Das HTTP-Protokoll hat keine Längenbeschränkung für GET und POST. Sicherheit und Unsicherheit haben nichts mit GET und POST zu tun.
  3. GET generiert ein TCP-Datenpaket; POST generiert zwei TCP-Datenpakete. Bei GET-Anfragen sendet der Browser den HTTP-Header und die Daten zusammen und der Server antwortet mit 200 (Rückgabedaten); bei POST sendet der Browser zuerst den Header und der Server antwortet mit 100 Weiter, und der Browser sendet erneut Daten und der Server antwortet mit 200 ok (Daten zurückgeben).

HTTP-StatuscodeEnzyklopädie

1, 1** Information, der Server hat die Anfrage erhalten und der Anforderer muss den Vorgang weiter ausführen
2, 2* * Erfolg, der Vorgang wurde erfolgreich empfangen und verarbeitet
3, 3** Umleitung, weitere Vorgänge sind erforderlich, um die Anfrage abzuschließen
4, 4** Client-Fehler, die Anfrage enthält ein Syntaxfehler oder Die Anfrage konnte nicht abgeschlossen werden
5, 5** Serverfehler, beim Verarbeiten der Anfrage durch den Server ist ein Fehler aufgetreten

Das obige ist der detaillierte Inhalt vonHTTP-Anfrageheader. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!