You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@abdera.apache.org by Richard Jones <ri...@googlemail.com> on 2011/04/16 14:40:59 UTC
chunked Transfer-Encoding forbidden
Hi Folks,
I'm a new user with Abdera, and am having some problems getting an
Abdera client to talk to my AtomPub server running behind Apache, based
around chunked Transfer-Encoding, and wonder if anyone can help.
Basically, I'm executing:
resp = client.execute(
"POST", url.toString(),
new SWORDMultipartRequestEntity(deposit),
options);
Where SWORDMultipartRequestEntity is home-baked but very similar to
MultipartRelatedRequestEntity (it adds a few extra headers at the Media
Part mime boundary and puts a Content-Disposition on the Entry Part).
When I run this, I get a 411 Content-Length required response, and the
Apache log says:
chunked Transfer-Encoding forbidden: /sss/col-uri/ca0f
I ran a curl command against my AtomPub server:
curl -i -X POST --data-binary "@multipart.dat"
-H 'Content-Type:
multipart/related;boundary="===============0670350989=="'
-H 'MIME-Version: 1.0'
-H 'Packaging: http://purl.org/net/sword/package/default'
http://localhost/sss/col-uri/ca0f
where @multipart.dat is a mock-up of the kind of multipart/related
request I want to make.
The request was successful, and I chased it with wireshark, which gave
me the following output:
POST /sss/col-uri/ca0f HTTP/1.1
User-Agent: curl/7.19.7 (i486-pc-linux-gnu) libcurl/7.19.7
OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
Host: localhost
Accept: */*
Content-Type: multipart/related; boundary="===============0670350989=="
MIME-Version: 1.0
Packaging: http://purl.org/net/sword/package/default
Content-Length: 49557
Expect: 100-continue
HTTP/1.1 100 Continue
So there was a 100 Continue response and then the content deposit went
as planned. When I chase the relevant equivalent bit of code coming
from Abdera I get:
POST /sss/col-uri/ca0f HTTP/1.1
User-Agent: Abdera/v1.0-SNAPSHOT
Host: localhost
Expect: 100-continue
Transfer-Encoding: chunked
Content-Type: Multipart/Related;
boundary="1302955343423";type="application/atom+xml;type=entry"
HTTP/1.1 411 Length Required
The Main differences I can see are:
1/ The Content-Type header from Abdera is slightly differently
constructed (mime boundary accepted) - can't see that this is the problem.
2/ There is a Transfer-Encoding: chunked header rather than a
Content-Length header in the Abdera call. This seems to be the culprit.
Perhaps support for Transfer-Encoding: chunked is an option in Apache,
or perhaps I need to set the Content-Length myself? Any tips gratefully
appreciated.
In the mean time, other than that I have to say that Abdera is a joy to
work with - it's giving me lots of space to do the things that I want.
All the best,
Richard
Re: chunked Transfer-Encoding forbidden
Posted by Richard Jones <ri...@googlemail.com>.
Hi Alistair,
Thanks - yes, you are right, neither Apache nor mod_wsgi enable chunked
transfer encoding by default. Eventually I found the answer in a change
log on the mod_wsgi scm, which allows you to turn it on :)
Cheers,
Richard
On 12/05/11 11:28, Alistair Miles wrote:
> Hi Richard,
>
> I'm far from an expert in either Apache or Abdera, but I'd be surprised if
> Apache (at least in the default configuration) allowed posting of content
> without a content-length header - I think this would be a potential denial of
> service vulnerability.
>
> Cheers,
>
> Alistair
>
> On Sat, Apr 16, 2011 at 01:40:59PM +0100, Richard Jones wrote:
>> Hi Folks,
>>
>> I'm a new user with Abdera, and am having some problems getting an
>> Abdera client to talk to my AtomPub server running behind Apache,
>> based around chunked Transfer-Encoding, and wonder if anyone can
>> help.
>>
>> Basically, I'm executing:
>>
>> resp = client.execute(
>> "POST", url.toString(),
>> new SWORDMultipartRequestEntity(deposit),
>> options);
>>
>> Where SWORDMultipartRequestEntity is home-baked but very similar to
>> MultipartRelatedRequestEntity (it adds a few extra headers at the
>> Media Part mime boundary and puts a Content-Disposition on the Entry
>> Part).
>>
>> When I run this, I get a 411 Content-Length required response, and
>> the Apache log says:
>>
>> chunked Transfer-Encoding forbidden: /sss/col-uri/ca0f
>>
>> I ran a curl command against my AtomPub server:
>>
>> curl -i -X POST --data-binary "@multipart.dat"
>> -H 'Content-Type:
>> multipart/related;boundary="===============0670350989=="'
>> -H 'MIME-Version: 1.0'
>> -H 'Packaging: http://purl.org/net/sword/package/default'
>> http://localhost/sss/col-uri/ca0f
>>
>> where @multipart.dat is a mock-up of the kind of multipart/related
>> request I want to make.
>>
>> The request was successful, and I chased it with wireshark, which
>> gave me the following output:
>>
>> POST /sss/col-uri/ca0f HTTP/1.1
>> User-Agent: curl/7.19.7 (i486-pc-linux-gnu) libcurl/7.19.7
>> OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
>> Host: localhost
>> Accept: */*
>> Content-Type: multipart/related; boundary="===============0670350989=="
>> MIME-Version: 1.0
>> Packaging: http://purl.org/net/sword/package/default
>> Content-Length: 49557
>> Expect: 100-continue
>>
>> HTTP/1.1 100 Continue
>>
>> So there was a 100 Continue response and then the content deposit
>> went as planned. When I chase the relevant equivalent bit of code
>> coming from Abdera I get:
>>
>> POST /sss/col-uri/ca0f HTTP/1.1
>> User-Agent: Abdera/v1.0-SNAPSHOT
>> Host: localhost
>> Expect: 100-continue
>> Transfer-Encoding: chunked
>> Content-Type: Multipart/Related;
>> boundary="1302955343423";type="application/atom+xml;type=entry"
>>
>> HTTP/1.1 411 Length Required
>>
>> The Main differences I can see are:
>>
>> 1/ The Content-Type header from Abdera is slightly differently
>> constructed (mime boundary accepted) - can't see that this is the
>> problem.
>>
>> 2/ There is a Transfer-Encoding: chunked header rather than a
>> Content-Length header in the Abdera call. This seems to be the
>> culprit.
>>
>>
>> Perhaps support for Transfer-Encoding: chunked is an option in
>> Apache, or perhaps I need to set the Content-Length myself? Any
>> tips gratefully appreciated.
>>
>> In the mean time, other than that I have to say that Abdera is a joy
>> to work with - it's giving me lots of space to do the things that I
>> want.
>>
>> All the best,
>>
>> Richard
Re: chunked Transfer-Encoding forbidden
Posted by Alistair Miles <al...@googlemail.com>.
Hi Richard,
I'm far from an expert in either Apache or Abdera, but I'd be surprised if
Apache (at least in the default configuration) allowed posting of content
without a content-length header - I think this would be a potential denial of
service vulnerability.
Cheers,
Alistair
On Sat, Apr 16, 2011 at 01:40:59PM +0100, Richard Jones wrote:
> Hi Folks,
>
> I'm a new user with Abdera, and am having some problems getting an
> Abdera client to talk to my AtomPub server running behind Apache,
> based around chunked Transfer-Encoding, and wonder if anyone can
> help.
>
> Basically, I'm executing:
>
> resp = client.execute(
> "POST", url.toString(),
> new SWORDMultipartRequestEntity(deposit),
> options);
>
> Where SWORDMultipartRequestEntity is home-baked but very similar to
> MultipartRelatedRequestEntity (it adds a few extra headers at the
> Media Part mime boundary and puts a Content-Disposition on the Entry
> Part).
>
> When I run this, I get a 411 Content-Length required response, and
> the Apache log says:
>
> chunked Transfer-Encoding forbidden: /sss/col-uri/ca0f
>
> I ran a curl command against my AtomPub server:
>
> curl -i -X POST --data-binary "@multipart.dat"
> -H 'Content-Type:
> multipart/related;boundary="===============0670350989=="'
> -H 'MIME-Version: 1.0'
> -H 'Packaging: http://purl.org/net/sword/package/default'
> http://localhost/sss/col-uri/ca0f
>
> where @multipart.dat is a mock-up of the kind of multipart/related
> request I want to make.
>
> The request was successful, and I chased it with wireshark, which
> gave me the following output:
>
> POST /sss/col-uri/ca0f HTTP/1.1
> User-Agent: curl/7.19.7 (i486-pc-linux-gnu) libcurl/7.19.7
> OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
> Host: localhost
> Accept: */*
> Content-Type: multipart/related; boundary="===============0670350989=="
> MIME-Version: 1.0
> Packaging: http://purl.org/net/sword/package/default
> Content-Length: 49557
> Expect: 100-continue
>
> HTTP/1.1 100 Continue
>
> So there was a 100 Continue response and then the content deposit
> went as planned. When I chase the relevant equivalent bit of code
> coming from Abdera I get:
>
> POST /sss/col-uri/ca0f HTTP/1.1
> User-Agent: Abdera/v1.0-SNAPSHOT
> Host: localhost
> Expect: 100-continue
> Transfer-Encoding: chunked
> Content-Type: Multipart/Related;
> boundary="1302955343423";type="application/atom+xml;type=entry"
>
> HTTP/1.1 411 Length Required
>
> The Main differences I can see are:
>
> 1/ The Content-Type header from Abdera is slightly differently
> constructed (mime boundary accepted) - can't see that this is the
> problem.
>
> 2/ There is a Transfer-Encoding: chunked header rather than a
> Content-Length header in the Abdera call. This seems to be the
> culprit.
>
>
> Perhaps support for Transfer-Encoding: chunked is an option in
> Apache, or perhaps I need to set the Content-Length myself? Any
> tips gratefully appreciated.
>
> In the mean time, other than that I have to say that Abdera is a joy
> to work with - it's giving me lots of space to do the things that I
> want.
>
> All the best,
>
> Richard
--
Alistair Miles
Head of Epidemiological Informatics
Centre for Genomics and Global Health <http://cggh.org>
The Wellcome Trust Centre for Human Genetics
Roosevelt Drive
Oxford
OX3 7BN
United Kingdom
Web: http://purl.org/net/aliman
Email: alimanfoo@gmail.com
Tel: +44 (0)1865 287669