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 !
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?
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 …
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 ?!!!
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.
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 ?!
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?
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.
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…
and the v3.00 User Guide says exactly the same - but I think they are both [color=red]lying!
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.
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
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!