You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by David Boyer <ma...@gmail.com> on 2009/09/17 19:47:24 UTC
RpcServlet doesn't handle Transfer-Encoding
When I hit RpcServlet(gadgets-metadata) with a POST that has
Transfer-Encoding chunked the server returns a 411 Length Required.
Problem is the http 1.1 spec says that Content-Length should not be
there, and more importantly Content-Length must be ignored if the
Transfer-Encoding is present and has a value other than identity.
I've done a basic search of the mailing list and I can't see why the
length checks are present, but I suspect they are some basic DOS
protection. Just to give additional information all of my posted
content to /gadgets/metadata have had Content-Length settings in the
range of 210-220. The check if the content length is too long is
1024*128. Seems to be a check to avoid malformed or maliciously
formed POSTS. I suspect there are issues around transfer-encoding
where someone could choke a server with extremely large POST entity
requests. So RpcServlet may have avoided that issue, but did so by
breaking the http 1.1 spec.
Attached are a unit test (JUnit 3, requires httpclient 3.1) and a
patch file that causes the test to pass. I don't believe that this is
necessarily the right fix, but to know that I would have to know why
the checks are there.
Can anyone shed any light on this issue?
--
David S Boyer (IBM Jazz Web UI Foundation)
mangr3n@gmail.com
703.499.8728(h)
703.408.5395(m)
Re: RpcServlet doesn't handle Transfer-Encoding
Posted by David Boyer <ma...@gmail.com>.
yes, I do mean that one, and I'm glad to hear that it was applied thanks.
On Thu, Oct 15, 2009 at 5:17 PM, Paul Lindner <li...@inuus.com> wrote:
> I don't think you mean SHINDIG-1187 do you?
> In any case I applied Mark's patch yesterday.
>
>
> On Wed, Oct 14, 2009 at 10:41 AM, David Boyer <ma...@gmail.com> wrote:
>
>> Can someone please address this issue in RC1?
>>
>> The issue is https://issues.apache.org/jira/browse/SHINDIG-1187.
>>
>>
>>
>> On Tue, Sep 22, 2009 at 11:21 AM, David Boyer <ma...@gmail.com> wrote:
>> > Louis,
>> >
>> > I'll create a different patch that does what you suggest which is
>> > remove those checks. Mark Weitzel is going to create a defect and
>> > attach that patch to the defect.
>> >
>>
>>
>>
>> --
>> David S Boyer
>> mangr3n@gmail.com
>> 703.499.8728(h)
>> 703.408.5395(m)
>>
>
--
David S Boyer
mangr3n@gmail.com
703.499.8728(h)
703.408.5395(m)
Re: RpcServlet doesn't handle Transfer-Encoding
Posted by Paul Lindner <li...@inuus.com>.
I don't think you mean SHINDIG-1187 do you?
In any case I applied Mark's patch yesterday.
On Wed, Oct 14, 2009 at 10:41 AM, David Boyer <ma...@gmail.com> wrote:
> Can someone please address this issue in RC1?
>
> The issue is https://issues.apache.org/jira/browse/SHINDIG-1187.
>
>
>
> On Tue, Sep 22, 2009 at 11:21 AM, David Boyer <ma...@gmail.com> wrote:
> > Louis,
> >
> > I'll create a different patch that does what you suggest which is
> > remove those checks. Mark Weitzel is going to create a defect and
> > attach that patch to the defect.
> >
>
>
>
> --
> David S Boyer
> mangr3n@gmail.com
> 703.499.8728(h)
> 703.408.5395(m)
>
Re: RpcServlet doesn't handle Transfer-Encoding
Posted by David Boyer <ma...@gmail.com>.
Can someone please address this issue in RC1?
The issue is https://issues.apache.org/jira/browse/SHINDIG-1187.
On Tue, Sep 22, 2009 at 11:21 AM, David Boyer <ma...@gmail.com> wrote:
> Louis,
>
> I'll create a different patch that does what you suggest which is
> remove those checks. Mark Weitzel is going to create a defect and
> attach that patch to the defect.
>
--
David S Boyer
mangr3n@gmail.com
703.499.8728(h)
703.408.5395(m)
Re: RpcServlet doesn't handle Transfer-Encoding
Posted by David Boyer <ma...@gmail.com>.
Louis,
I'll create a different patch that does what you suggest which is
remove those checks. Mark Weitzel is going to create a defect and
attach that patch to the defect.
Re: RpcServlet doesn't handle Transfer-Encoding
Posted by Louis Ryan <lr...@google.com>.
I suspect the length checks are there as you say because of DOS protection
but they don't exist in other servlets in Shindig. As a general rule DOS
protections like these should be a cross-cutting feature like a servlet
filter or a capability in your reverse-proxy rather than embedded in
individual servlets. Im inclined just to remove it.
Anyone else have an opinion on this
On Thu, Sep 17, 2009 at 10:47 AM, David Boyer <ma...@gmail.com> wrote:
> When I hit RpcServlet(gadgets-metadata) with a POST that has
> Transfer-Encoding chunked the server returns a 411 Length Required.
> Problem is the http 1.1 spec says that Content-Length should not be
> there, and more importantly Content-Length must be ignored if the
> Transfer-Encoding is present and has a value other than identity.
>
> I've done a basic search of the mailing list and I can't see why the
> length checks are present, but I suspect they are some basic DOS
> protection. Just to give additional information all of my posted
> content to /gadgets/metadata have had Content-Length settings in the
> range of 210-220. The check if the content length is too long is
> 1024*128. Seems to be a check to avoid malformed or maliciously
> formed POSTS. I suspect there are issues around transfer-encoding
> where someone could choke a server with extremely large POST entity
> requests. So RpcServlet may have avoided that issue, but did so by
> breaking the http 1.1 spec.
>
> Attached are a unit test (JUnit 3, requires httpclient 3.1) and a
> patch file that causes the test to pass. I don't believe that this is
> necessarily the right fix, but to know that I would have to know why
> the checks are there.
>
> Can anyone shed any light on this issue?
> --
> David S Boyer (IBM Jazz Web UI Foundation)
> mangr3n@gmail.com
> 703.499.8728(h)
> 703.408.5395(m)
>