Do not omit mandatory null content-length headers.

[mefyl]

The code currently reuses the code that determines whether a body should be read to determine whether a Content-Length header should be sent. However, for unchunked bodies of size 0, there is no body to read, but Content-Length: 0 is still mandatory for methods which may allow a body.

[rgrinberg]

@anuragsoni can you have a look?

[anuragsoni]

This looks good!

One note for future releases is to re-think how we track this in a future release as the encoding field this api depends on has been deprecated and will be removed in a future release (https://github.com/mirage/ocaml-cohttp/blob/master/http/src/http.mli#L388-L389)

[anuragsoni]

Hmm, that said, going through the async implementation again as a refresher, it looks like the current scenarios that are handled are:

• Servers fill in transfer encoding based on response bodies returned by users: https://github.com/mirage/ocaml-cohttp/blob/master/cohttp-async/src/server.ml#L109-L113 but lwt's implementation is similar.
• Clients fill in transfer encoding for outgoing requests: https://github.com/mirage/ocaml-cohttp/blob/master/cohttp-lwt/src/client.ml#L19-L33

The header module does perform a check if there's a transfer encoding header present before updating the header value so this change should be safe, but it'd be nice to either run this header setup in the individual backends based on the body types written for each backend (I think I lean towards linking the encoding type to the body as opposed to request as it is in the current cohttp version), or rethink whether the encoding type needs to be deprecated/removed.

[mefyl]

I also think it would be better to automatically deduce this from the body type and entirely abstract this from the users, because in the vast majority of cases they do not care. HTTP 1 is a bit messy because it mixes transport-level and application-level headers, but IMO content-length, transfer-encoding etc. should not be manually configurable by the user. If they really want some manual control on these, Request and Response provide primitives to manually send headers and chunks of body.

It is also probably possible and desirable to factor all these behavior once and for all in the common cohttp library to ensure consitency across all backends. I'm currently toying with such factoring in this MR.

[anuragsoni]

I also think it would be better to automatically deduce this from the body type

+1

It is also probably possible and desirable to factor all these behavior once and for all in the common cohttp library to ensure consitency across all backends. I'm currently toying with such factoring in this MR.

I haven't looked at the other pull-request, (and I'm not a maintainer for cohttp so take this with a grain of salt), but I found the shared signature/functor approach in cohttp a little awkward to work with when working on the new parser. This was exacerbated in the lwt backend where there was another layer added on top with the split between lwt, lwt.unix, and mirage.

Personally my preference after working on cohttp and opium (which used to be built on top of cohttp), leans towards using the http library for writing the common types and operations on them (header manipulation, stateless parsers for requests/responses/chunked bodies etc), and letting each IO backend orchestrate the rest according to the best options available in each backend. As I see it, having the shared signatures in cohttp is a little helpful for maintainers of cohttp in that there can be a shared set of features that can be managed centrally, in-practice the shared signatures have been a little awkward to work with personally since any interaction with them necessitates instantiating a functor, which leads to either other libraries building on top of cohttp also being functorized, and/or picking a single backend and sticking to it.

[mefyl]

I'm not talking about functors here, just :

module type CLIENT = sig
  type 'a io
  val call : request -> body -> (response * body) io
end

module Client_lwt : CLIENT with type 'a io = 'a Lw.t
module Client_eio : CLIENT with type 'a io = 'a

The end users don't need to instantiate a functor, they can use the values directly. Actually they needn't even know there is a common signature. The only aim would be indeed to help maintaining consistency, so that when switching backend the same feature set / API is guaranteed. One could also imagine writing a library that works with any cohttp backend, but that would indeed require a functor.

Now here I'm not even arguing for / against this, I just want to emulate the current API word-for-word to ease possible adoption of that MR, without bundling API design choice in it; that can come in a second time.

These discussion probably belong over there, for that matter :)

[rgrinberg]

LGTM. can you rebase?

[mseri]

Thanks!