undefinedfix
Sign in

Questions about accept parameter setting in HTTP request

jdwgu edited in Tue, 08 Nov 2022

If accept is not set in HTTP request header, what is the default receive type? Is it determined by the type of back-end return value? If accept is set, but the back-end return value type is inconsistent with the set accept type, what will happen? Will an error be reported directly?

3 Replies
Demian
commented on Tue, 08 Nov 2022

Question 1: if accept is not set in HTTP request header, what is the default receive type? The default receiving type has different default values according to different browsers. For specific reference https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Content_ negotiation/Accept_ %E9%BB%98%E8%AE%A4%E5%80%BC

Question 2: is it determined by the type of the back-end return value? If accept is set, but the back-end return value type is inconsistent with the set accept type, what will happen and will the error be reported directly? There are two negotiation methods (active negotiation and responsive content negotiation). The latter one is rarely used. In any case, the server will return active content negotiation whatever the client supports: for example, the client text / HTML. When the server receives the request, it will check whether the supported negotiation content format supports text / HTML, If the server does not support this format, it will return a 406 not accept error.

Responsive Content Negotiation: this process is more than proactive, that is, the server is not sure whether it can return the correct content, so it gives the client 300 a response and tells the client some URLs for the client to choose. The client selects a reasonable URL and then initiates a request. If it does not support 406, it is also the same

Extended content negotiation reminds me of the negotiation of HTTPS encryption. The following is the list of elliptic curve encryption negotiation supported in nginx service

 ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:

After receiving the list, the client can select an elliptic curve encryption method supported by itself, and then tell the server, and both sides will use the agreed asymmetric encryption algorithm to encrypt and decrypt. If you don't support any of them, it's a handshake failure.

talatccan
commented on Tue, 08 Nov 2022

1. Accept means that the client tells the server, "what type of response do I want to receive?". If it is not set, there will be no default value and no hope.

2. The front end and back end agree by themselves, and the browser itself does not do special processing. In fact, in most cases, the back end will not process this field (if you want to, I didn't hear that).

PaulELI
commented on Tue, 08 Nov 2022

Finally found the relevant information: example: accept: text / HTML, application / XHTML + XML, application / XML; q = 0.9, image / webp, image / apng, /; q = 0.8 indicates the data format supported by the client, or the content type that the client "wants" to accept. It's just hope here, but it's up to the server to decide what kind of content type the server returns. However, no matter what kind of content type the server returns, the client will receive the response message. It's impossible to say that the server can't receive the response message because of different content types, which is not in line with the HTTP protocol specification.

We send a get or post request through the browser, and the field is automatically added by the browser, and the value of the field will not be parsed on the server side; we can set the value of the field through Ajax request or other means, but it is usually not set.

The application scenario of this field can be as follows: there are two terminals, for example, one is a pure text reader, such as kinder (can't display pictures), and the other is a mobile terminal (can play pictures and videos). Both of them request information about "zebra" from the server. At this time, the server needs to determine what kind of information should be returned by what kind of terminal, and then it can be used You can judge according to the information of accept. If the parsed value of accept is "text / plain", it means that the client only supports the text type; if it is as in the above example, it means that the client can use text, pictures and videos. If we don't judge, when we return an image to the text reader, it may display garbled code.