Solved: Request handling for an external application load ...

mountaincode2 · 09-18-2024 02:44 AM

Hello, i have a query in relation to:

https://cloud.google.com/load-balancing/docs/https#request_handling

the doc says:

1. Content-Length: this header is removed only when the request has Transfer-Encoding: chunked.

Would it be more accurate to say the following:
the `Content-Length` header is removed and then added as a "trailer" when the client sends an entity-body using chunked transfer encoding.

2. The doc also says: Transfer-Encoding: the header Transfer-Encoding: chunked is added when the HTTP OPTIONS request has a body and the protocol is HTTP or HTTPS.

But how can the HTTP OPTIONS request have a body? The Options request is used by the client simply to discover which HTTP methods the resource responds to.

My understanding of `Transfer-encoding: chunked`: Sometimes a server needs to send an entity-body without knowing important facts like how large it is. Rather than omitting HTTP headers like Content-Length and Content-MD5, which rely on this information, the server may decide to send the entity-body in chunks, and put Content-Length after the entity body rather than before.

So, what is the relationship between HTTP OPTIONS request and `Transfer-Encoding: chunked` header?

Can someone please help me understand the flow here for both Request handling and the subsequent section, Response Handling.

Thank you!

jamespatrickm

Hi @mountaincode2,

@mountaincode2 wrote:

the doc says:

1. Content-Length: this header is removed only when the request has Transfer-Encoding: chunked.

Would it be more accurate to say the following:
the `Content-Length` header is removed and then added as a "trailer" when the client sends an entity-body using chunked transfer encoding.

I agree with the first half. Content-Length is indeed removed when Transfer-Encoding: chunked and the body is sent in chunks (not added as a trailer). I believe when a server processes Transfer-Encoding: chunked, it usually does not add the Content-Length as a trailer.

@mountaincode2 wrote:

2. The doc also says: Transfer-Encoding: the header Transfer-Encoding: chunked is added when the HTTP OPTIONS request has a body and the protocol is HTTP or HTTPS.

But how can the HTTP OPTIONS request have a body? The Options request is used by the client simply to discover which HTTP methods the resource responds to.

My understanding of `Transfer-encoding: chunked`: Sometimes a server needs to send an entity-body without knowing important facts like how large it is. Rather than omitting HTTP headers like Content-Length and Content-MD5, which rely on this information, the server may decide to send the entity-body in chunks, and put Content-Length after the entity body rather than before.

Yes, HTTP OPTIONS is primarily used to check supported methods for a specific resource. Most of the time, OPTIONS is not expected to have a body but it is technically possible. Albeit not common practice, HTTP specifications do allow for a body in any request including OPTIONS.

So, what is the relationship between HTTP OPTIONS request and `Transfer-Encoding: chunked` header?

HTTP OPTIONS relates to Transfer-Encoding chunked when: HTTP OPTIONS has a request body. The server will use Transfer-Encoding: chunked when it does not know the size of the body ahead of time. Also, the use of Transfer-Encoding: chunked is to allow the sender to send data in segments without the need to specify total length upfront(commonly used in scenarios where the body is generated dynamically).

These documentations are a good read regarding the topic:

I hope the above information is helpful.

View solution in original post

jamespatrickm

Hi @mountaincode2,

@mountaincode2 wrote:

the doc says:

1. Content-Length: this header is removed only when the request has Transfer-Encoding: chunked.

Would it be more accurate to say the following:
the `Content-Length` header is removed and then added as a "trailer" when the client sends an entity-body using chunked transfer encoding.

I agree with the first half. Content-Length is indeed removed when Transfer-Encoding: chunked and the body is sent in chunks (not added as a trailer). I believe when a server processes Transfer-Encoding: chunked, it usually does not add the Content-Length as a trailer.

@mountaincode2 wrote:

2. The doc also says: Transfer-Encoding: the header Transfer-Encoding: chunked is added when the HTTP OPTIONS request has a body and the protocol is HTTP or HTTPS.

But how can the HTTP OPTIONS request have a body? The Options request is used by the client simply to discover which HTTP methods the resource responds to.

My understanding of `Transfer-encoding: chunked`: Sometimes a server needs to send an entity-body without knowing important facts like how large it is. Rather than omitting HTTP headers like Content-Length and Content-MD5, which rely on this information, the server may decide to send the entity-body in chunks, and put Content-Length after the entity body rather than before.

Yes, HTTP OPTIONS is primarily used to check supported methods for a specific resource. Most of the time, OPTIONS is not expected to have a body but it is technically possible. Albeit not common practice, HTTP specifications do allow for a body in any request including OPTIONS.

So, what is the relationship between HTTP OPTIONS request and `Transfer-Encoding: chunked` header?

HTTP OPTIONS relates to Transfer-Encoding chunked when: HTTP OPTIONS has a request body. The server will use Transfer-Encoding: chunked when it does not know the size of the body ahead of time. Also, the use of Transfer-Encoding: chunked is to allow the sender to send data in segments without the need to specify total length upfront(commonly used in scenarios where the body is generated dynamically).

These documentations are a good read regarding the topic:

I hope the above information is helpful.

mountaincode2

Thank you, @jamespatrickm . This is very helpful!

Request handling for an external application load balancer