You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Roland Zink <Ro...@mobixell.com> on 2012/12/14 13:51:20 UTC

chunked encoded POST data transform

Hi,

 

I try to develop a plugin for TS 3.2 to modify post data. This fails for
POST requests without content-length. There is a bug report TS-1335 (TS
crashed when null_transform running as a request transform) which reports
something similar.

 

In my case it seems to fail because of
HttpSM::state_request_wait_for_transform_read:

 

    } else {

      // No content length from the post.  This is a no go

      //  since http spec requires content length when

      //  sending a request message body.  Change the event

      //  to an error and fall through

      event = VC_EVENT_ERROR;

      Log::error("Request transformation failed to set content length");

    }

 

The comment seem to indicate that a post request always needs a
content-length header. This is different from my interpretation of RFC2616
which for example states in section 4.4:

 

   For compatibility with HTTP/1.0 applications, HTTP/1.1 requests

   containing a message-body MUST include a valid Content-Length header

   field unless the server is known to be HTTP/1.1 compliant.

 

Is the comment wrong and this is a bug or is this correct? Btw. without
plugin this seems to work fine.

 

Regards,

Roland

 

 

(gdb) bt

#0  HttpSM::state_request_wait_for_transform_read (this=0x2b3011211b10,

    event=2000, data=0x2b301c0102f8) at HttpSM.cc:1136

#1  0x000000000056c7a8 in HttpSM::main_handler (this=0x2b3011211b10,

    event=2000, data=0x2b301c0102f8) at HttpSM.cc:2447

#2  0x00000000004e2564 in Continuation::handleEvent (this=0x2b3011211b10,

    event=2000, data=0x2b301c0102f8)

    at ../iocore/eventsystem/I_Continuation.h:146

#3  0x000000000052b713 in TransformTerminus::handle_event (

    this=0x2b301c010260, event=1, edata=0x2b30201f08d0) at Transform.cc:177

#4  0x00000000004e2564 in Continuation::handleEvent (this=0x2b301c010260,

    event=1, data=0x2b30201f08d0) at
../iocore/eventsystem/I_Continuation.h:146

#5  0x00000000006e3104 in EThread::process_event (this=0x2b3003e37010,

    e=0x2b30201f08d0, calling_code=1) at UnixEThread.cc:142

#6  0x00000000006e3317 in EThread::execute (this=0x2b3003e37010)

    at UnixEThread.cc:191

#7  0x00000000006e2342 in spawn_thread_internal (a=0x3131e20) at
Thread.cc:88

#8  0x0000003afa207851 in start_thread () from /lib64/libpthread.so.0

#9  0x0000003af96e811d in clone () from /lib64/libc.so.6


RE: chunked encoded POST data transform

Posted by Roland Zink <Ro...@mobixell.com>.
If the client is 1.1 compliant and sends the request with chunked encoding
then it should know that the server is 1.1.

Roland


-----Original Message-----
From: Alan M. Carroll [mailto:amc@network-geographics.com] 
Sent: Monday, December 17, 2012 10:40 PM
To: Roland Zink
Subject: Re: chunked encoded POST data transform

Your interpretation seems reasonable, the catch is "the server is known to
be 1.1 compliant". Is it reasonable to infer that if the request is marked
as 1.1?

Friday, December 14, 2012, 6:51:20 AM, you wrote:

> The comment seem to indicate that a post request always needs a 
> content-length header. This is different from my interpretation of 
> RFC2616 which for example states in section 4.4:

>  
>    For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
>    containing a message-body MUST include a valid Content-Length header
>    field unless the server is known to be HTTP/1.1 compliant.



Re: chunked encoded POST data transform

Posted by "Alan M. Carroll" <am...@network-geographics.com>.
Your interpretation seems reasonable, the catch is "the server is known to be 1.1 compliant". Is it reasonable to infer that if the request is marked as 1.1?

Friday, December 14, 2012, 6:51:20 AM, you wrote:

> The comment seem to indicate that a post request always needs a
> content-length header. This is different from my interpretation of RFC2616
> which for example states in section 4.4:

>  
>    For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
>    containing a message-body MUST include a valid Content-Length header
>    field unless the server is known to be HTTP/1.1 compliant.