abdera-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Jones <rich.d.jo...@googlemail.com>
Subject Re: chunked Transfer-Encoding forbidden
Date Thu, 12 May 2011 15:27:43 GMT
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


Mime
View raw message