Looks good, pushed as f7ab8b59..9199e5aa (with updates to documentation). Happy hacking!
Christian On 10/15/18 9:03 PM, Gauthier Haderer wrote: > Hi, > > I attached a patch which adds a response flag to force version to HTTP > 1.0 in > responses but still maintaining connection management. > > The existing MHD_RF_HTTP_VERSION_1_0_ONLY flag already changes MHD's > behavior to apply HTTP 1.0 rules for connection management. When > enabled, MHD sends a response using the same version as used in the > request (is this normal?). > > What I want is MHD responding as a HTTP 1.0 server with support for > connection management headers would do. This is what the > MHD_RF_HTTP_VERSION_1_0_RESPONSE response flag is for. > > You can even combine it with MHD_RF_HTTP_VERSION_1_0_ONLY to change the > response's HTTP version while maintaining strict compliance with HTTP > 1.0 regarding connection management. > > This solution is not perfect as this flag is set on the response which > is created after header processing. So MHD will behave as a HTTP 1.1 > server until the response is queued. It means that an invalid HTTP 1.1 > request will fail even if the response is sent with HTTP 1.0 and the > request would be valid if interpreted with this version. For example, > this request will fail in strict mode: > > GET /dummy HTTP/1.1 > > as the Host header is missing and is mandatory in HTTP 1.1, but it > should succeed when interpreted with HTTP 1.0. > > I don't think this is a big issue in practice. Besides, being able to > change the HTTP version on a response basis is really convenient when > using MHD in a test framework where I need to validate a client against > HTTP 1.1 AND HTTP 1.0 as I can start a single server for the whole set > of tests to run. > > Do you think this is something you could consider integrating mainstream? > > Regards, > > > Gauthier
signature.asc
Description: OpenPGP digital signature