>
> On Wed, Mar 4, 2015 at 3:41 PM, Umesh Sehgal <umesh.seh...@gmail.com>
> wrote:
>
>>
>>
>> On Tue, Mar 3, 2015 at 8:31 PM, Rainer Jung <rainer.j...@kippdata.de>
>> wrote:
>>
>>> Am 03.03.2015 um 13:45 schrieb Umesh Sehgal:
>>>
>>>  On Mon, Mar 2, 2015 at 6:20 PM, Rainer Jung <rainer.j...@kippdata.de>
>>>> wrote:
>>>>
>>>>  Am 02.03.2015 um 13:34 schrieb Umesh Sehgal:
>>>>>
>>>>>   On Mon, Mar 2, 2015 at 5:25 PM, Umesh Sehgal <umesh.seh...@gmail.com
>>>>> >
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>   On Mon, Mar 2, 2015 at 3:52 PM, Rainer Jung <rainer.j...@kippdata.de
>>>>> >
>>>>>
>>>>>> wrote:
>>>>>>>
>>>>>>>   Am 02.03.2015 um 11:02 schrieb Umesh Sehgal:
>>>>>>>
>>>>>>>>
>>>>>>>>   Thanks for the quick reply, I tried using the maxSwallowSize with
>>>>>>>>
>>>>>>>>> increased
>>>>>>>>> value but to no effect. The max size that I have been able to
>>>>>>>>> upload is
>>>>>>>>> ~16
>>>>>>>>> KB. I also see that the maxSwallowSize got introduced with update
>>>>>>>>> 55
>>>>>>>>> but
>>>>>>>>> the behavior I'm seeing is 50 update onwards, is there any other
>>>>>>>>> param
>>>>>>>>> too?
>>>>>>>>> is there any logging that can be turned on tomcat to help debug?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  Please do not top post. For the rest see below.
>>>>>>>>
>>>>>>>>    On Mon, Mar 2, 2015 at 2:32 PM, Rainer Jung <
>>>>>>>> rainer.j...@kippdata.de>
>>>>>>>>
>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>>    Am 02.03.2015 um 09:34 schrieb Umesh Sehgal:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>     Hi,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  We recently upgraded our application's tomcat from 7.0.30 to
>>>>>>>>>>> 7.0.59.
>>>>>>>>>>> After
>>>>>>>>>>> upgrade the file upload feature has broken. I have been able to
>>>>>>>>>>> nail
>>>>>>>>>>> it
>>>>>>>>>>> down to the point that the problem manifests 7.0.50 onwards.
>>>>>>>>>>> Here is
>>>>>>>>>>> the
>>>>>>>>>>> exception that I see inside logs:
>>>>>>>>>>>
>>>>>>>>>>>       Caused by: java.net.SocketException: Connection reset by
>>>>>>>>>>> peer:
>>>>>>>>>>> socket
>>>>>>>>>>> write error
>>>>>>>>>>> at java.net.SocketOutputStream.socketWrite0(Native Method)
>>>>>>>>>>> at java.net.SocketOutputStream.socketWrite(Unknown Source)
>>>>>>>>>>> at java.net.SocketOutputStream.write(Unknown Source)
>>>>>>>>>>> at sun.security.ssl.OutputRecord.writeBuffer(Unknown Source)
>>>>>>>>>>> at sun.security.ssl.OutputRecord.write(Unknown Source)
>>>>>>>>>>>
>>>>>>>>>>> Also, I notice that the problem doesn't happen with a 2KB file
>>>>>>>>>>> but
>>>>>>>>>>> 2MB. I
>>>>>>>>>>> don't see anything obvious in the 7.0.50 changelog which could
>>>>>>>>>>> explain
>>>>>>>>>>> this
>>>>>>>>>>> behavior. Can someone please provide some pointer as what could
>>>>>>>>>>> be
>>>>>>>>>>> causing
>>>>>>>>>>> this?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>   https://bz.apache.org/bugzilla/show_bug.cgi?id=57617
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Fixed for next 7.0.60 in
>>>>>>>>>>
>>>>>>>>>> http://svn.apache.org/r1659295
>>>>>>>>>>
>>>>>>>>>> The original change can be found looking for "maxSwallowSize" in
>>>>>>>>>> the
>>>>>>>>>> changelog
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    Could it be "If a request that includes an Expect:
>>>>>>>>> 100-continue header
>>>>>>>>>
>>>>>>>> receives anything other than a 2xx response, close the connection
>>>>>>>> This
>>>>>>>> protects against misbehaving clients that may not sent the request
>>>>>>>> body
>>>>>>>> in
>>>>>>>> that case and send the next request instead. (markt) "?
>>>>>>>>
>>>>>>>> It was changed in 7.0.49, but 49 was not released, so 50 was the
>>>>>>>> first
>>>>>>>> version with this change.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Rainer
>>>>>>>>
>>>>>>>>
>>>>>>>>  I did see this in changelog but in the captured traffic don't see
>>>>>>> any
>>>>>>> expect 100 header request. Any other way I can confirm this on the
>>>>>>> tomcat
>>>>>>> side?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Umesh
>>>>>>>
>>>>>>>
>>>>>>>  Can you please point me to SVN change for :
>>>>>> "If a request that includes an Expect: 100-continue header receives
>>>>>> anything other than a 2xx response, close the connection This protects
>>>>>> against misbehaving clients that may not sent the request body in that
>>>>>> case
>>>>>> and send the next request instead. (markt) "?
>>>>>>
>>>>>>
>>>>> http://svn.apache.org/r1540689
>>>>>
>>>>>
>>>>> Hi Rainer,
>>>>>
>>>>
>>>> Thanks, I think the problem is indeed caused by this change. I
>>>> downloaded
>>>> the tomcat source, removed the above change from AbstractHttp11Processor
>>>> and delpoyed the updated jar. The file upload didn't work right away
>>>> but at
>>>> least now maxSwallowSize is honored and I can upload the files per the
>>>> size
>>>> specified.
>>>>
>>>> I did the above work to confirm, but of course I don't want to ship it
>>>> carrying modified code. Can you please suggest as what could be done in
>>>> this case?
>>>>
>>>
>>> OK, good to know. I'd say now it would be good to find out why your
>>> webapp sends a non-2xx response code and hwich it is.
>>>
>>> Since you already suceeded to build tomcat, simply add a custom log or
>>> System.out.println() statement printing response.getStatus() where the
>>> change in r1540689 was added and tell us what it is for the failing uploads.
>>>
>>> Regards,
>>>
>>> Rainer
>>>
>>>
>>> I see 401 response code. Not sure why it's 401 but may be because of the
>> way authorization is done.
>>
>> Thanks,
>> Umesh
>>
>
> But shouldn't it by any means swallow the remaining bytes before closing
> the connection?
>
> Thanks,
>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>>
>> Investigating further around the "401" response returned by tomcat during
> Expect: 100-continue processing, I interestingly notice that if I use a
> different client (Abdera client) to post the request, there isn't any 401
> response for the Expect: 100-continue. However  for my apache common
> httpClient(3.1 version) there is a 401 in tomcat logs while processing
> Expect: 100-continue.
>

Is there any known problem with this combination? Anyone?

-Umesh

Reply via email to