Hi, Thank you very much for so detailed explanation ☺
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 <k...@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.galanmarq...@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<https://www.rfc-editor.org/rfc/rfc9110.html#field.host> on requests and Date<https://www.rfc-editor.org/rfc/rfc9110.html#field.date> on responses" (See RFC9112, 5.3-5<https://www.rfc-editor.org/rfc/rfc9110.html#section-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<https://gitlab.com/karlson2k/libmicrohttpd/-/blob/v0.9.75/ChangeLog#L305>. 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<https://www.rfc-editor.org/rfc/rfc9110.html#section-5.3-5>) and "...a sender MUST NOT generate multiple field lines with the same name in a message..." (here<https://www.rfc-editor.org/rfc/rfc9110.html#section-5.3-3>). 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
