-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Pawel,
On 2/7/19 19:41, Pawel Veselov wrote:
> Sorry for a rather rude intrusion.
If you think it's rude, why did you do it?
> On Thu, Feb 7, 2019 at 4:18 PM Christopher Schultz
> wrote:
>
>> Chunked encoding is like sending a bunch of small
Sorry for a rather rude intrusion.
On Thu, Feb 7, 2019 at 4:18 PM Christopher Schultz
wrote:
> Chunked encoding is like sending a bunch of small HTTP message-pieces
> (I have to be careful about my wording here, since "part" actually
> means something in multipart messages
May be just
<
chuck.caldar...@unisys.com> wrote:
> > From: Bhavesh Mistry [mailto:mistry.p.bhav...@gmail.com]
> > Subject: Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length
> Corrupting
> > Parsing logic for Subsequent Request
>
> > I am stating following when you h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Bhavesh,
On 2/7/19 19:11, Christopher Schultz wrote:
> The Content-Length of the PUT request says "I'm going to send 128
> bytes". The server is required to accept exactly 128 bytes, no more
> no less.
There is another option, here, but also
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Bhavesh,
On 2/7/19 18:40, Bhavesh Mistry wrote:
> Hi Mark,
>
> I understand what you are stating the root of issue originated with
> the client (wrong client). I am stating following when you have
> request/response on the same TCP connection.
> From: Bhavesh Mistry [mailto:mistry.p.bhav...@gmail.com]
> Subject: Re: Fwd: Tomcat-embed-core-9.0.12.jar bug about Content-Length
Corrupting
> Parsing logic for Subsequent Request
> I am stating following when you have request/response on the same TCP
> connection. for
Hi Mark,
I understand what you are stating the root of issue originated with the
client (wrong client). I am stating following when you have
request/response on the same TCP connection. for example,
My understanding (please correct me if my wrong):
Client
On 07/02/2019 20:05, Bhavesh Mistry wrote:
> Hi Mark,
>
> There is no way to validate the END of a request for PUT call and if
> Content-Lenght does not match what client had sent payload body then
> rejected it and reset position.
You can't do that. The only way to determine how much data to
Hi Mark,
There is no way to validate the END of a request for PUT call and if
Content-Lenght does not match what client had sent payload body then
rejected it and reset position.
If content length does match then reject PUT request, and then close the
connection for PUT call not for subsequent
On 07/02/2019 18:48, Bhavesh Mistry wrote:
> Hello Tomcat Developers,
>
> I have a unique situation about HTTP Protocol PAYLOAD parsing and
> Content-Length Header.
There is nothing unique here.
> When PUT/POST Content-Length is NOT correct
> (client send wrong Content-Lenght), the tomcat is
10 matches
Mail list logo
