Retrieve Content-Length from HTTP Response


#1

Hi everybody,

i would like to retrieve Content-Length from the HTTP response :
So my code is as follow :

void GPRS_HTTP_Hdlr(wip_event_t *ev, void *ctx)
{
  ascii Buffer[50];
    u32 u32Buf = 50;
    int plouf;

    wip_channel_t tChannel;
    tChannel = ev->channel;

    switch(ev->kind)
    {
        case WIP_CEV_OPEN :      
            break;

        case WIP_CEV_READ : 
            
            plouf = wip_getOpts(tChannel, WIP_COPT_HTTP_HEADER, "content-length",   Buffer, u32Buf , WIP_COPT_END);
            TRACE((4,"plouf : %d", plouf));
            plouf = wip_getOpts(tChannel, WIP_COPT_HTTP_HEADER, "content-type",   Buffer, u32Buf , WIP_COPT_END);
            TRACE((4,"plouf : %d", plouf));
             plouf = wip_getOpts(tChannel, WIP_COPT_HTTP_HEADER, "Host",   Buffer, u32Buf , WIP_COPT_END);
             TRACE((4,"plouf : %d", plouf));
            break;

        case WIP_CEV_WRITE : 
            break;

        case WIP_CEV_ERROR :
            break;

        case WIP_CEV_PEER_CLOSE : 
            break;

        default :
            break;
    }
}

But, wip_getOpt() return always WIP_CERR_INVALID (which means : some option has been passed with an invalid value)
I don’t understand why ?!
May be someone can help me !
Thanks in advance !

Regards


#2

In WIP_CEV_READ you should only read data and copy over to some buffer that you can process later.
In WIP_CEV_PEER_CLOSE you should do your getOpts instead.

Other than that:
Does content-type work as expected?
What WIP version are you using?


#3

Is that for all of your calls, or just the one to get the content-length?

I note that the WIP User Guide doesn’t document what happens if the requested header filed is not present… :unamused:


#4

Just looked again at my WIP User Guide (v2.00), and it says that wip_getOpts should be used in the WIP_CEV_OPEN Event - there is no mention of using it in WIP_CEV_PEER_CLOSE nor WIP_CEV_READ …


#5

I used WIP version 2.00.32

I have currently a program which run properly with a fix buffer size of 10Ko.

But, I would like to retrieve Content-Length from the response, in order to instanciate a dynamic buffer (adl_memGet()) with the size specified in “Content-Length” field. This is why i use wip_getOpt() in case of WIP_CEV_READ event.
Then, after i will fill the buffer.

In sample described above, all wip_getOpts() return WIP_CERR_INVALID ! I don’t understand why ?!!!


#6

I was merely going by the sample application provided in the WIP documentation, and in that they are doing wip_getOpts in PEER_CLOSE to retrieve content-type.


#7

if i use wip_getOpt(tChannel, WIP_COPT_HTTP_HEADER, “content-length”, Buffer, u32Buf , WIP_COPT_END) when WIP_CEV_OPEN event occured the following error is returned :

WIP_CERR_CSTATE (which means : the channel is not ready to get option. still in initialization, or is already closed).

so, this is why i do it in WIP_CEV_READ case (see my first post).

Here my needs :

-> WIP_CEV_OPEN event
-> WIP_CEV_READ event
-> retrieve content-length (with HTTP_COPT_HEADER option)
-> instanciate buffer thanks to content-length
-> receive data in this buffer
-> WIP_CEV_CLOSE
-> Save Buffer

anyone, has never used wip_getOpts() with HTTP_COPT_HEADER option for retrieve data from the response ?!


#8

Looking at your sample code, it would be a wise idea to actually read data into some buffer before doing wip_getOpts.
Otherwise, wouldn’t the data just be waiting to be read in some internal buffer that is not automatically checked by getOpts?


#9

Thanks for your help tobias and awneil,

I was asking myself if it’s the correct syntax :

ascii Buffer[50]; 
u32 u32Buf = 50; 

wip_getOpts(tChannel, WIP_COPT_HTTP_HEADER, "content-length",   Buffer, u32Buf , WIP_COPT_END);

do i made a mistake ? according to the userguide all is right, but as described in my first post, wip_getOpt() return WIP_CERR_INVALID ! So…


#10

How far do you get if you are only doing content-type?
Does the http server you test against actually send content-length?

I did some testing, and wip_getOpts for content-type at least can be checked without actually doing any wip_read.
If I try content-length, I get WIP_CERR_INVALID as well.
It could be that content-length simply isn’t supported yet.

My testing has been done with WIP 3.0.0.6.


#11

I was under the impression that WIP simply did a string match using the supplied string - so there would be no specific “support” (nor possible lack thereof) for any particular header… :confused:


#12

I telnetted into my test server and there I got the content-length.

Based on testing, I don’t think they do any string comparison to find the header, but if they actually do, I have no idea what is wrong.


#13

thanks of all,

Life is a mystery… now it works… why ? i don’t now !

here is my sample code for those who would like instanciate a dynamic buffer according to their HTTP reponse header “content-length” :

ascii * HTTP_Resp_Buffer;
u32 u32SizeBuffer;

GPRS_HTTP_Hdlr()
{

ascii tmpbuf[20];
u32 size;

...

WIP_CEV_OPEN :
u32SizeBuffer = 0;
break;

WIP_CEV_READ :
if(u32SizeBuffer == 0)
{
   plouf = wip_getOpts(tCh, WIP_COPT_HTTP_HEADER, "content-length",   tmpbuf,  20, WIP_COPT_END);
   TRACE((4,"content-length : %s", tmpbuf));
   TRACE((4,"plouf : %d", plouf));
   size = wm_atoi(tmpbuf);
   u32SizeBuffer = size ;
   HTTP_Resp_Buffer = (ascii *) adl_memGet(u32SizeBuffer );

}

// Fill the buffer


break;

WIP_CEV_CLOSE:

// save buffer in flash

// release Buffer
...
break;

}

i try to find why this morning it wasn’t running and i will let you know if i find !

Best regards !


#14

This is really far-fetched, but could you try the same but with a larger buffersize?

So like tmpbuf[50];
and specifying 50 in the call to wip_getOpts as well…


#15

In fact, it says:

and the v3.00 User Guide says exactly the same - but I think they are both [color=red]lying! :angry:

I have tried sending a GET to a dumb socket listener:
it receives my GET, and my Open-AT Application receives a WIP_CEV_OPEN - even though the dumb socket listener sends no repsonse at all!

The v2.00 guide goes on to say, for the WIP_CEV_OPEN event:

This part has been removed from the v3.00 Guide, which now adds later:

The example at the end of the v2.00 User Guide shows calling wip_getOpts for the OPEN event;

The example at the end of the v3.00 User Guide has, indeed, been changed and shows calling wip_getOpts for the PEER_CLOSE event.


#16

An update:

Yes, wip_getOpts does return [b]WIP_CERR_INVALID /b when you ask for a header field that is not present!

It would be much more helpful to have a specific return code to indicate that the requested field was not present!


#17

Yes, they are [color=red]lying! :angry:

What is actually happening in my application is that I get one WIP_CEV_READ event when the Header is available, and another WIP_CEV_READ event when the Body is available


#18

Yep, you’re right

On my side, i haven’t still understood why last week my code doesn’t work the first times… but, problem seems resolved so…


#19

strange ! there is some holes in their documents… not the first time i see that… i will pay attention on my side !


#20

So, the question is: are you sure that the Content-Length field was actually present in the responses that you were receiving?

Note that the Content-Length field is not always present; in fact, if the server uses ‘chunked’ encoding, the HTTP spec specifically requires that it should not be present!

See: wavecom.com/modules/movie/sc … ht=chunked