libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] Response headers order change between 0.9.70 and 0.9


From: Evgeny Grin
Subject: Re: [libmicrohttpd] Response headers order change between 0.9.70 and 0.9.75
Date: Wed, 11 Jan 2023 11:33:08 +0300
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1

I would recommend you to implement more relaxed header testing. If you use some generic text parser, you may find the end of the header block by looking for "CRLFCRLF" then check all text before the last "CRLF". The first line must be always the "status line", the other lines must be header lines. You may take them line-by-line and check whether each line is one of the expected lines. Also it would be a good idea to implement a check for duplicated lines. This approach would require more work on the implementation, but it would be future-proof as the order of the automatic headers is not guaranteed and it could be updated with new RFCs (or new RFC reading).

Please note that suggested algorithm is suitable only for regression testing and not suitable for any HTTP client. Any real HTTP client should implement much more checks and use another approach for parsing. Also UTF-8 text processing is fine for regression testing (as MHD doesn't use any characters outside US ASCII), while for the real HTTP client usage of UTF-8 in headers may break normal HTTP processing or even introduce security weakness.

--
Wishes,
Evgeny

11.01.2023 10:31, FERMIN GALAN MARQUEZ wrote:

Hi,

 

Thank you very much for so detailed explanation J

 

The order is significant in my case due to the regression testing I do on my project. My tests are very strict and include expectations even in the order of HTTP headers. Thus, this change in the order of the headers involves a huge number of changes (I have thousands of such tests).

 

However I understand the changes in libmicrohttpd are for good, so it’s something that I should fix on my test regression sooner or later.

 

Thanks!

 

Best regards,

 

------

Fermín

 

De: Evgeny Grin <k2k@yandex.ru>
Enviado el: miércoles, 11 de enero de 2023 7:53
Para: libmicrohttpd development and user mailinglist <libmicrohttpd@gnu.org>
CC: FERMIN GALAN MARQUEZ <fermin.galanmarquez@telefonica.com>
Asunto: Re: [libmicrohttpd] Response headers order change between 0.9.70 and 0.9.75

 

Hi Fermín,

MHD internally has two types of response headers: user headers and automatic (mandatory) headers.

For automatic headers MHD now follow RFC recommendation: "...it is good practice to send header fields that contain additional control data first, such as Host on requests and Date on responses" (See RFC9112, 5.3-5). Probably it would make sense to move "Content-Length" and "Transfer-Encoding" headers to the top as well.

For user headers MHD recently fixed the wrong output order. Before the fix, user headers were sent in as reversed sequence relative to the order of headers addition (LIFO). Currently MHD sends user headers exactly in the same order as user added them (FIFO),  with documented exceptions, like special handling of the "Connection" headers. The Changelog entry is here.

However, these changes are mostly cosmetics, as RFC requires "The order in which field lines with differing field names are received in a section is not significant." (here) and "...a sender MUST NOT generate multiple field lines with the same name in a message..." (here). Previous RFC versions have similar requirements. Anyway, for user defined headers you have full control of the header order: the first added header will be sent as the first user header.

Could you share more details about the situation where the order of the headers is important?

--
Wishes,
Evgeny

10.01.2023 20:17, FERMIN GALAN MARQUEZ wrote:

Hi,

 

I’ve recently upgrade from libmicrohttpd 0.9.70 to 0.9.75 in my project (for reference, this one: https://github.com/telefonicaid/fiware-orion).

 

I have observed a curious change of behavior in response headers. In 0.9.70 the server responses like this:

 

HTTP/1.1 400 Bad Request

Content-Length: 129

Content-Type: application/json

Fiware-Correlator: 86753370-9108-11ed-91ea-000c29583ca5

Date: Tue, 10 Jan 2023 17:02:11 GMT

 

But in 0.9.75 response is like this:

 

HTTP/1.1 400 Bad Request

Date: Tue, 10 Jan 2023 17:02:11 GMT

Fiware-Correlator: 86753370-9108-11ed-91ea-000c29583ca5

Content-Type: application/json

Content-Length: 129

 

That is, same headers but in different order.

 

At this point, I have a couple of questions, please:

 

1.       Why this has changed between 0.9.70 and 0.9.75? I have tried to find the reason in the changelog at https://github.com/Karlson2k/libmicrohttpd/blob/master/ChangeLog but it is a bit confusing…

2.       Is there any way of keeping the older behavior?

 

Any feedback is welcome. Thanks in advance for that!

 




Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]