Envoy - Chunked body unclear behavior (request/response)

[Itay Ben-Am]

Hi , 

Came across something that looks like a bug. 

I'm working with External processing filter.

I'm sending http/1.1 request with chunked body to ENVOY Client:

curl -v -H "Transfer-Encoding: chunked" -d "a=b"  http://10.188.146.136:18000.

Envoy client sends it to my gRPC server without 'content-length' and 'transfer-encoding'.

On the contrary when Envoy client Gets http/1.1 response with chunked body , it does send header message with 'transfer-encoding: chunked' and without 'content-length.

In both cases  body message is dechunked properly , 

But why is the behavior different between request and response?

What's the expected behavior?

In case we are getting header message without 'transfer-encoding' and without 'content-length' how can we know if we should expect body message?

Thx in Advance!

Itay

[Zizon Qiu]

On Sun, Dec 19, 2021 at 10:39 PM 'Itay Ben-Am' via envoy-dev <envo...@googlegroups.com> wrote:

Hi , 

Came across something that looks like a bug. 

I'm working with External processing filter.

I'm sending http/1.1 request with chunked body to ENVOY Client:

curl -v -H "Transfer-Encoding: chunked" -d "a=b"  http://10.188.146.136:18000.

I have a quick try on this command and notice a message output by curl:

* Mark bundle as not supporting multiuse

So, I suspect that curl will not encode -d data automatically,

and either it silence drop this conflict header(chunked encoding) nor envoy handle it by ignore/verifying the

acutely payload is not chunked.

Envoy client sends it to my gRPC server without 'content-length' and 'transfer-encoding'.

As of this, the former case will be more likely(no content length presented).

 

On the contrary when Envoy client Gets http/1.1 response with chunked body , it does send header message with 'transfer-encoding: chunked' and without 'content-length.

Envoy behaving expectly should be the consequence of upstream implicit auto-encode body in chunked, like what go http std library does. 

 

In both cases  body message is dechunked properly , 

But why is the behavior different between request and response?

What's the expected behavior?

In case we are getting header message without 'transfer-encoding' and without 'content-length' how can we know if we should expect body message?

Thx in Advance!

Itay

--
You received this message because you are subscribed to the Google Groups "envoy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to envoy-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/envoy-dev/8c9c491b-6092-433f-a1d6-56f37912643bn%40googlegroups.com.

[Alyssa (Rzeszutek) Wilk]

That's quite surprising.  Any chance you can attach a trace and Envoy logs so we can look into it?

cheers,

Alyssa

[Raúl Gutiérrez Segalés]

Are the buffer and/or decompression filters involved by any chance?

To view this discussion on the web visit https://groups.google.com/d/msgid/envoy-dev/CAPnEgyEWpsjun98MemMBTgG4M_QRZ3J0Ndmy9uTFdnj%3Dz021Ww%40mail.gmail.com.

[Lizan Zhou]

Is the gRPC server an external processing server?

In case we are getting header message without 'transfer-encoding' and without 'content-length' how can we know if we should expect body message?

In filters there's a flag end_stream indicates whether it is the last, isn't that sent to an ext proc server?

 

To view this discussion on the web visit https://groups.google.com/d/msgid/envoy-dev/CAMUR%3DWjLQ0kgwKNiFLSNSSifwB0aZ%3DQTS%2B6_me02%3DW%2BrMq7nBQ%40mail.gmail.com.