Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of umesh.sehgal@gmail.com
 designates 209.85.215.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54F5CCD6.8070000@kippdata.de>
References: 
 <CA+HvTQbYQNtje8CF9_3W_NUV8MErOR1gChJXEAr-CVXENzqfuQ@mail.gmail.com>
	<CA+HvTQb6JWbmLOKDM+RbOAteMBbqdKcAM_erkzvtxw7XSgwB_w@mail.gmail.com>
	<54F42715.6040800@kippdata.de>
	<CA+HvTQbnH5f=a_UW8+1V0a2fwOOUejWuz9m_SiXU7LvxdGaY3w@mail.gmail.com>
	<54F439D6.9030904@kippdata.de>
	<CA+HvTQbjwaPj1vsJct5iFnk=grz0GAGiS+MmqJ3QqOvSp3f4Bg@mail.gmail.com>
	<CA+HvTQZcHuDJTzSv=gMqksv2fqKU2ZxMmBxXFX2FtcnCOspYkg@mail.gmail.com>
	<54F45CA5.1020009@kippdata.de>
	<CA+HvTQZa0NCLYgdaaP_xx9yaFgTa53_1aym8jTCZgREsx6_A5A@mail.gmail.com>
	<54F5CCD6.8070000@kippdata.de>
Date: Wed, 4 Mar 2015 15:41:39 +0530
Message-ID: 
 <CA+HvTQYZaCbDPYpTXpgqas4UKD_e9PrYF5VGZqvBfd0bVyZK6A@mail.gmail.com>
Subject: Re: Fwd: File upload fails after upgrade to 7.0.59
From: Umesh Sehgal <umesh.sehgal@gmail.com>
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: multipart/alternative; boundary=001a11c284e264af35051073adb7

--001a11c284e264af35051073adb7
Content-Type: text/plain; charset=UTF-8

On Tue, Mar 3, 2015 at 8:31 PM, Rainer Jung <rainer.jung@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.jung@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.sehgal@gmail.com>
>>>
>>>> wrote:
>>>>
>>>>
>>>   On Mon, Mar 2, 2015 at 3:52 PM, Rainer Jung <rainer.jung@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.jung@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

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

--001a11c284e264af35051073adb7--