SpringMVC-un résumé de la pratique du projet de requête HTTP

(1) Introduction à MIME

(1. Introduction

structure grammaticale

type/subtype         类型/独立类型

Un type de média (souvent appelé extensions de messagerie Internet polyvalentes ou type MIME) est une norme utilisée pour exprimer la nature et le format d'un document, d'un fichier ou d'un flux d'octets. Il est défini et normalisé dans l'IETF RFC 6838.

Important: les navigateurs utilisent généralement le type MIME (plutôt que l'extension de fichier) pour déterminer comment gérer l'URL, il est donc très important que le serveur Web ajoute le type MIME correct dans l'en-tête de la réponse. Si la configuration est incorrecte, le navigateur peut déformer le contenu du fichier, le site Web ne fonctionnera pas correctement et le fichier téléchargé sera traité de manière incorrecte.

La structure de composition de MIME est très simple, elle est composée de deux chaînes séparées par un «/» entre le type et le sous-type. Aucun espace n'est autorisé. type représente une catégorie indépendante qui peut être divisée en plusieurs sous-catégories. Le sous-type représente chaque type après la subdivision.

Le type MIME n'est pas sensible à la casse, mais la méthode traditionnelle d'écriture est en minuscules.

(2) Type indépendant

text/plain
text/html
image/jpeg
image/png
audio/mpeg
audio/ogg
audio/*
video/mp4
application/*
application/json
application/javascript
application/ecmascript
application/octet-stream

S'il n'y a pas de sous-type spécifique pour le type de fichier texte, text / plain est utilisé. De même, le fichier binaire n'a pas de sous-type spécifique ou connu, c'est-à-dire que l'application / le flux d'octets est utilisé.

(2) Quatre méthodes courantes de soumission de données POST

Le protocole stipule que les données soumises par POST doivent être placées dans le corps de l'entité, mais le protocole ne spécifie pas la méthode de codage que les données doivent utiliser. En fait, les développeurs peuvent décider eux-mêmes complètement du format du corps du message, à condition que la dernière requête HTTP envoyée respecte le format ci-dessus.

Cependant, pour que les données soient envoyées, il est logique que le serveur les analyse avec succès. Les langages serveur courants tels que php, python, etc., ainsi que leurs frameworks, ont des fonctions intégrées pour analyser automatiquement les formats de données courants. Le serveur sait généralement comment le corps du message dans la demande est codé en fonction du champ Content-Type dans les en-têtes de la demande, puis analyse le corps. Ainsi, en ce qui concerne le schéma de soumission de données POST, il comprend deux parties: Content-Type et la méthode de codage du corps du message. Commençons à les présenter formellement.

[Application / x-www-form-urlencoded]
Cela devrait être le moyen le plus courant de soumettre des données via POST. Le formulaire natif du navigateur, si l’attribut enctype n’est pas défini, il se terminera par

POST http://www.example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8

title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

Premièrement, le type de contenu est spécifié comme application / x-www-form-urlencoded; deuxièmement, les données soumises sont codées selon key1 = val1 & key2 = val2, et key et val sont transcodés en URL. La plupart des langages côté serveur ont un bon support pour cette méthode. Par exemple, en PHP, ${}_{P}OST{[}^{\prime }Titl{e}^{«}]PeutêtrepourobtenirobteniràTITLEdesvaleurs,$_POST [ » sous « ] peut être rangée de sous.

Plusieurs fois, lorsque nous soumettons des données avec Ajax, nous utilisons également cette méthode. Par exemple, dans Ajax de JQuery, la valeur par défaut de Content-Type est
"application / x-www-form-urlencoded; charset = utf-8"

[Multipart / form-data]
C'est une autre façon courante de soumettre des données POST. Lorsque nous utilisons le formulaire pour télécharger des fichiers, le type d'enctype du formulaire doit être égal à multipart / form-data.
[Application / json]

Le Content-Type de l'application / json n'est certainement pas étranger à l'en-tête de réponse. En fait, de plus en plus de personnes l'utilisent désormais comme en-tête de requête pour indiquer au serveur que le corps du message est une chaîne JSON sérialisée. En raison de la popularité de la spécification JSON, tous les principaux navigateurs, à l'exception des versions inférieures d'IE, prennent en charge nativement JSON.stringify, et les langages côté serveur ont également des fonctions de traitement de JSON, vous ne rencontrerez donc aucun problème avec JSON.

Le format JSON prend en charge les données structurées qui sont beaucoup plus complexes que les paires clé-valeur, ce qui est également utile.

[Texte / xml]
Il s'agit d'une spécification d'appel à distance qui utilise HTTP comme protocole de transmission et XML comme méthode de codage. Une requête XML-RPC typique ressemble à ceci:

POST http://www.example.com HTTP/1.1 
Content-Type: text/xml

<?xml version="1.0"?>
<methodCall>
    <methodName>examples.getStateName</methodName>
    <params>
        <param>
            <value><i4>41</i4></value>
        </param>
    </params>
</methodCall>

Le protocole XML-RPC est simple, fonctionnel et peut être implémenté dans plusieurs langues. Il est également largement utilisé, comme l'API XML-RPC de WordPress, le service ping des moteurs de recherche, etc. En JavaScript, il existe également des bibliothèques prêtes à l'emploi qui prennent en charge l'interaction de données de cette manière, qui peuvent bien prendre en charge les services XML-RPC existants. Cependant, je pense personnellement que la structure XML est encore trop gonflée et qu'il est plus flexible et pratique d'utiliser JSON dans des scénarios généraux.

(3) Comment SpringMVC reçoit les requêtes POST

(1) Type de contenu par défaut

Content-Type est transmis dans application / x-www-form-urlencoded, le formulaire par défaut.
Cette méthode de transmission consiste à construire la demande de publication normale du formulaire de transmission
. Deux paramètres sont requis dans le contrôleur. En même temps, veuillez noter que cela ne peut pas être ajouté @RequestBody Sinon, une exception 405 sera levée et les paramètres seront remplis dans les paramètres sous forme de chaînes et de tableaux

méthode de réception application / x-www-form-urlencoded:

1 ： @RequestParam («nom»)

2: utilisez la même chaîne de nom de clé pour recevoir le nom de chaîne, le nom doit correspondre

3: utilisez la classe d'entité pour recevoir, l'attribut correspondant injectera la valeur, la méthode setgeter est requise et le nom est incohérent et ne peut pas être injecté

4: Utilisez request.getParameter ("name"); pour recevoir

（2） application / json

Content-Type est transmis sous la forme application / json. De
cette manière, une chaîne au format json
doit être transmise. Le contrôleur doit utiliser une chaîne pour accepter la chaîne json.
Si des annotations sont utilisées, @RequestBody doit être ajouté
. Lisez le contenu du corps dans le champ de requête, puis désérialisez cette chaîne en json en objet. Si vous souhaitez qu'elle soit automatiquement convertie en objet, vous devez configurer l'outil de sérialisation json dans la configuration SpringMVC.

La méthode de référence est la suivante:

1: Utilisez @RequestBody String pour recevoir, directement à une chaîne ne peut pas être reçu, de cette façon reçoit une chaîne JSON, vous devez la convertir vous-même

2: @RequestBody plus réception POJO ou chaîne

3: @RequestBody Map <String, Object> json, il est plus pratique d'utiliser Map pour recevoir, pas besoin de construire un objet VO

4: Obtenez manuellement getReader () ou getInputStream () à partir du flux. Notez que la couche inférieure de la méthode précédente est également reçue de cette manière et que le flux ne peut pas être répété

Paramètres de réception: un objet avec plusieurs attributs uniques

(4) La différence entre getParameter () getInputStream () et getReader ()

request.getParameter ()
request.getInputStream ()
request.getReader ()
Ces trois méthodes récupèrent toutes les données soumises à partir de l'objet de requête, mais elles ont des utilisations différentes.

Choisissez différentes méthodes en fonction de la méthode de codage des données de soumission de formulaire.

Un type d'attribut clé du formulaire en HTML:

(1) Enctype = application / x-www-form-urlencoded
Cette méthode de codage est la méthode de codage par défaut.
Le résultat encodé se présente généralement sous la forme field1 = value2 & field2 = value2 & ..., comme name = aaaa & password = bbbb.
Les formulaires couramment utilisés sont également codés de cette manière. L'API Servlet prend en charge le décodage de cette méthode de codage. Il vous suffit d'appeler la méthode getParameter () dans la classe ServletRequest pour obtenir les champs et les données du formulaire utilisateur.
Inconvénients: bien
que cette méthode de codage (application / x-www-form-urlencoded) soit simple, elle n'est pas capable de transmettre de gros blocs de données binaires.

(2) Multipart / form-data
Pour des données telles que de gros blocs de nombres binaires, le navigateur utilise une autre méthode de codage, à savoir la méthode de codage "multipart / form-data":

Le navigateur peut facilement envoyer ensemble les données et les fichiers du formulaire. Cette méthode de codage définit d'abord une chaîne qui ne peut pas apparaître dans les données en tant que délimiteur, puis l'utilise pour séparer chaque segment de données, et chaque segment de données correspond à une zone d'entrée dans le formulaire de page HTML, y compris un L'attribut content-disposition indique certaines informations sur ce segment de données. Si le contenu du segment de données est un fichier, il y aura également un attribut Content-Type, puis les données elles-mêmes. Si vous soumettez des données de cette manière, vous devez utiliser request.getInputStream ( ) ou request.getReader () pour obtenir les données soumises, l'utilisation de request.getParameter () ne peut pas obtenir les données soumises.

Les trois méthodes request.getParameter (), request.getInputStream () et request.getReader () sont en conflit, car le flux ne peut être lu qu'une seule fois.
Par exemple:
lorsque le contenu du formulaire est encodé avec enctype = application / x-www-form-urlencoded, les paramètres sont obtenus en appelant la méthode request.getParameter (), puis request.getInputStream () ou request.getReader () est au contenu du flux, car le système peut lire une fois les données soumises dans le formulaire sous la forme d'un flux lors de l'appel de request.getParameter (), et vice versa.

Lorsque le contenu du formulaire est encodé avec enctype = multipart / form-data, aucune donnée ne peut être obtenue même si request.getParameter () est appelée en premier, donc la méthode request.getParameter () est appelée pour request.getInputStream () ou request. getReader ().) Il n'y a pas de conflit, même si la méthode request.getParameter () a été appelée, les données du formulaire peuvent être obtenues en appelant request.getInputStream () ou request.getReader (), et request.getInputStream ( ) et request.getReader () sont identiques. La réponse ne peut pas être mélangée, et si elle est mélangée, une exception sera levée.

Dans la requête http, il y a Header et Body. Pour lire l'en-tête, utilisez request.getHeader ("..."); pour lire le Body, utilisez request.getReader (), mais getReader obtient un BufferedReader, qui doit être converti en chaîne.

 private static String getPostData(HttpServletRequest request) throws IOException {
    
    
     StringBuilder data = new StringBuilder();
     String line;
     BufferedReader reader;
     try {
    
    
         reader = request.getReader();
         while (null != (line = reader.readLine())) {
    
    
             data.append(line);
         }
     } catch (IOException ignored) {
    
    
         throw new IOException();
     }
     return data.toString();
 }

référence

https://imququ.com/post/four-ways-to-post-data-in-http.html

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Basics_of_HTTP/MIME_types