hackney icon indicating copy to clipboard operation
hackney copied to clipboard

Fails to PUT chunked encoding

Open fogfish opened this issue 6 years ago • 3 comments

I do feel this as duplicate to #285. Exactly same use-case and symptoms. However, I'd like to re-open issue for the discussion here. I do not think that it is a good idea to force usage of different client api depending on presence of HTTP header.

fogfish avatar May 15 '19 18:05 fogfish

@fogfish I'm not sure to follow, can you clarify a little bit what you mean? The send_request API is/was to reuse a manually started request. You can get and fetch a chunked encoded request using the "standard" API normally.

benoitc avatar May 21 '19 09:05 benoitc

bump :)

benoitc avatar May 23 '19 11:05 benoitc

Sorry ;-) Let me clarify this one again.

I do have exactly same issue as #285

hackney:request(... [{"Transfer-Encoding", "chunked"}] ...)

leads to the following message... The HTTP request headers are encoded with chunked encoding. It leads to rejection of the request by remote entity.

5f
GET / HTTP/1.1
Transfer-Encoding: chunked
User-Agent: hackney/1.15.1
Host: localhost:4747

You made a proposal as a possible solution of the problem

if you want to stream the request don't pass a body but a stram atom or a function. Looks at the readme.

As I understood, there are a separate function at hackney client to post HTTP content depending on the presence of Transfer-Encoding encoding header. E.g. hackney:request shall not be used if this header is present.

I am trying advice here that it is not a good idea to use different apis that depends on protocol parameters. E.g. As a client I still want to use most simplest methods hackney:request for everything.

I hope it made a clarification to my issue.

fogfish avatar May 23 '19 12:05 fogfish