En-tête de requête HTTP

Le client utilise le serveurAPIinterface , vous devez construire un en-tête de requête HTTP. Généralement, vous initialisez un NSMutableURLRequest, puis définissez la méthode de requête , le corps de la requête et l'en-tête de la requête comme suit :

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

La requête réseau de Yuantiku (

YTKNetwork) a encapsulé la méthode de requête, le corps de la requête, l'en-tête de la requête, etc., permettant aux utilisateurs de surcharger pour la personnalisation, notamment :

.>

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

L'en-tête de requête renvoie un dictionnaire en remplaçant la méthode

, puis sérialise la requête réseau dans la méthode - (NSDictionary *)requestHeaderFieldValueDictionary；
pour l'utiliser dans la construction de NSURLSessionTask - (AFHTTPRequestSerializer *)requestSerializerForRequest:(YTKBaseRequest *)request；<.>

Détaillé ci-dessous. Parlons de la signification de plusieurs champs dans l'en-tête de la requête :

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

signifie que le local peut recevoir des données dans format compressé, et le serveur compressera le gros fichier pendant le traitement. Puis le renverra au client une fois la réception terminée, il décompresse les données localement
gzip : utilisé pour. compression de fichiers dans le système UNⅨ, encodage gzip sur le protocole HTTP. Technologie utilisée pour améliorer les performances des applications WEB à fort trafic utilisent souvent gzip pour permettre aux utilisateurs de bénéficier de vitesses plus rapides. Cela fait généralement référence à une fonction installée dans le serveur WWW. quelqu'un accède au serveur. Lors de l'accès à un site Web, cette fonction du serveur compresse le contenu de la page Web et le transmet au navigateur de l'ordinateur visiteur pour l'afficher. Généralement, le contenu du texte brut peut être compressé à 40 % de la taille d'origine, accélérant ainsi. La transmission des données augmentera également la charge sur le serveur. Généralement, ce module fonctionnel est installé dans le serveur

• dégonfler : une donnée sans perte utilisant l'algorithme LZ77 et le codage Huffman. Technologie de compression sans algorithme breveté

• La différence entre l'encodage de contenu HTTP et la compression HTTP : Dans le protocole HTTP, le contenu (c'est-à-dire la partie du corps) peut être encodé, et gzip peut être utilisé. Encodage. Pour atteindre l'objectif de compression, vous pouvez également utiliser d'autres encodages pour brouiller ou chiffrer le contenu afin d'empêcher des tiers non autorisés de voir le contenu du document. Ce que nous appelons la compression HTTP est en fait un type d'encodage de contenu HTTP. .

• Processus de compression HTTP :

  1. Le client envoie une requête HTTP au serveur Web, et la requête contient Accept-Encoding : gzip, deflate (dites au serveur que. le navigateur le prend en charge.
2. Après avoir reçu la demande, le serveur génère la réponse originale, qui contient le type de contenu et la longueur du contenu d'origine.
• 3. Le serveur encode la réponse via gzip. Après l'encodage, l'en-tête contient Content-Type et Content-Length (taille compressée), et Content-Encoding : gzip est ensuite envoyé au client.

  4. Après avoir reçu la réponse, le client décode la réponse selon Content-Encoding:gzip. Après avoir obtenu la réponse originale, l'affichage des données est ensuite traité.
  
  
  
  

  Autres
 : compresser indique que l'entité utilise un programme de compression de fichiers Unix ; l'identité indique que l'entité n'est pas codée. C'est le cas par défaut lorsqu'il n'y a pas d'en-tête Content-Encoding. Les codages Gzip, Compress et Deflate sont tous des algorithmes de compression sans perte, utilisés pour réduire la taille des messages transmis sans entraîner de perte d'informations. Parmi eux, gzip est généralement le plus efficace et le plus utilisé.

• Content-Type

représente le type de contenu, fait généralement référence au Content-Type existant sur le client, qui est utilisé pour définir le type et L'encodage de la page Web détermine la forme et l'encodage dans lesquels le client lira le fichier. Autrement dit, il est utilisé pour identifier le type de données envoyées ou reçues. Le client détermine comment ouvrir les données en fonction de ce paramètre.

application/x-www-form-urlencoded : Les données sont codées sous forme de paires nom/valeur, qui est le format de codage standard multipart/form-data : Les données du formulaire sont codées sous forme de message ; , Chaque champ de la page correspond à une partie du message. text/plain : les données du formulaire sont codées sous forme de texte brut sans aucun contrôle ni caractère de formatage.
1. Lorsque action est obtenue, le navigateur utilise la méthode d'encodage x-www-form-urlencoded pour convertir les données du formulaire en chaîne (name1=value1&name2=value2...), puis convertit ce mot. Ajoutez la chaîne à la fin de l'URL, divisez-la avec ? et chargez cette nouvelle URL.
2. Lorsque l'action est publiée, le navigateur encapsule les données du formulaire dans le corps http puis les envoie au serveur. S'il n'y a pas de contrôle type=file, utilisez simplement l'application/x-www-form-urlencoded par défaut. Mais s'il existe type=file, multipart/form-data sera utilisé. Le navigateur divisera l'ensemble du formulaire en unités de contrôle et ajoutera Content-Disposition(form-data ou file), Content-Type (la valeur par défaut est text/plain), le nom (nom du contrôle) et d'autres informations. , puis ajoutez un séparateur (limite).

Content-Length

• représente la longueur de transmission de l'entité de message HTTP. Longueur de l'entité du message : Entity-length, la longueur du corps du message avant compression ;
  Longueur de transmission de l'entité du message : Content-length, la longueur du corps du message après compression. (Dictionnaire des paramètres assemblés)

Autorisation

• L'authentification de base HTTP est une méthode utilisée pour autoriser les navigateurs Web ou d'autres programmes clients Connectez-vous en fournissant des informations d'identification sous forme de nom d'utilisateur et de mot de passe lorsque cela est demandé. Le Mécanisme d'autorisation est déterminé selon les règles fixées par le serveur.

• La différence entre l'authentification et l'autorisation : si vous souhaitez monter à bord de l'avion, vous devez présenter votre carte d'identité et votre billet. La carte d'identité sert à prouver que Zhang San est bien vous. Zhang San, il s'agit d'une authentification ; et le billet doit prouver que vous, Zhang San, avez réellement acheté le billet et que vous pouvez monter à bord de l'avion, c'est une autorisation. Vous devez vous connecter au forum, saisir le nom d'utilisateur Zhang San, le mot de passe 1234, et le mot de passe est correct, ce qui prouve que vous Zhang San est bien Zhang San, il s'agit d'une authentification puis vérifiez que l'utilisateur Zhang San est un modérateur ; il a donc le pouvoir d’ajouter et de supprimer les messages d’autres personnes. C’est une autorisation.

La différence entre POST et GET

• D'un point de vue HTML :
  1. POST soumettra à nouveau la demande.
  2. L'adresse URL générée par GET peut être mise en signet, mais pas POST.
  3. Les requêtes GET seront activement mises en cache par le navigateur, mais POST ne le sera pas, sauf si elles sont définies manuellement.
  4. Les requêtes GET ne peuvent être codées qu'en URL, tandis que POST prend en charge plusieurs méthodes de codage.
  5. GET les paramètres de requête seront entièrement conservés dans l'historique du navigateur, tandis que les paramètres dans POST ne seront pas conservés.
  6. Les paramètres transmis dans l'URL de la requête GET ont des limites de longueur, mais il n'y a pas de limite de longueur pour le POST.
  7. Concernant le type de données du paramètre , GET n'accepte que les caractères ASCII, tandis que POST n'a aucune restriction.
  8. GET est moins sûr que POST car les paramètres sont directement exposés sur l'URL, il ne peut donc pas être utilisé pour transférer des informations sensibles.
  9. Les paramètres GET sont transmis via l'URL et POST est placé dans le corps de la requête.

• Du point de vue de HTTP :
  1. HTTP est un protocole basé sur TCP/IP sur la façon dont les données communiquent dans le World Wide Web. La couche inférieure de HTTP est TCP/IP. Ainsi, la couche inférieure de GET et POST est également TCP/IP, c'est-à-dire que GET/POST sont tous deux des liens TCP. GET et POST peuvent faire la même chose. Vous devez ajouter le corps de la requête à GET et les paramètres d'URL à POST. Techniquement, c'est tout à fait réalisable. HTTP n'est qu'une ligne directrice de comportement, tandis que TCP est la base de la façon dont GET et POST sont implémentés.
  2. Il n'y a aucune exigence pour HTTP Si la méthode est une donnée POST, elle doit être placée dans le BODY. Il n'y a aucune exigence. Si la méthode est GET, les données (paramètres) doivent être placées dans l'URL et non dans le BODY. Autrement dit, GET et POST n'ont rien à voir avec la manière dont les données sont fournies. Le protocole HTTP n'a pas de limite de longueur pour GET et POST. La sécurité et l'insécurité n'ont rien à voir avec GET et POST.
  3. GET génère un paquet de données TCP ; POST génère deux paquets de données TCP. Pour les requêtes GET, le navigateur enverra l'en-tête http et les données ensemble, et le serveur répondra avec 200 (renvoyant les données) ; pour POST, le navigateur enverra l'en-tête en premier et le serveur répondra avec 100 continuer, et le navigateur enverra à nouveau les données, et le serveur répondra avec 200 ok (renvoyant des données).

Code d'état HTTPEncyclopédie

1, 1** Information, le serveur a reçu la demande et le demandeur doit continuer à effectuer l'opération
2, 2* * Succès, l'opération a été reçue et traitée avec succès
3, 3** Redirection, d'autres opérations sont nécessaires pour terminer la demande
4, 4** Erreur client, la demande contient un erreur de syntaxe ou Impossible de terminer la requête
5, 5** Erreur du serveur, une erreur s'est produite pendant que le serveur traitait la requête

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!