RE: Problems with data POST (returns -1)

-----Original Message-----
From: Michel Philip 
Sent: Thursday, January 31, 2002 11:18 AM
To: 'Manuele Kirsch Pinheiro'
Subject: RE: Problems with data POST (returns -1)


Hi Manuele

Thanks for the very kind answer.
It helps to know that one can help!

> I discovered what was my problem, and, unfortunally, 
> it seems that really it's not the same that Alik and Rob found...

Maybe you can think this.
However you gave them the rigth libw3 way to solve 
the 'connection timeout' issue.

> when we set the request's output format to "WWW_RAW",
> [...] libwww pass the server's response directly to the chunk 
> with all headers 
> (I think that libwww doesn't analize the headers in this case)...

I've been suprissed for in this case how the lib could know
the request is done and calls the terminate callback?
It just can't and for all HTTP/1.1 request must let the channel
open 'til the server decide to close it.
I've check "WWW_RAW" output_format and you're absolutly right. 
All my request went in timeout.
I was not knowing this output format for let the default format
unchanged ("WWW_PRESENT") or I set it to "WWW_SOURCE" whenever 
I don't want the content to be parsed.


> I applied this patch with no problems, 
> but I didn't have enough time to apply the others. 
> I'll try to do it in the next week, and after I tell 
> you if it's ok for request without rawBytesCount...

Thanks for your help.

Michel.

-----Original Message-----
From: Manuele Kirsch Pinheiro
[mailto:Manuele.Kirsch_Pinheiro@inrialpes.fr]
Sent: Thursday, January 24, 2002 5:51 PM
To: Michel Philip
Cc: 'www-lib@w3.org'; 'alik@witesite.com'
Subject: Re: Problems with data POST (returns -1)


Hi everybody!

At first place, I would like to thank Michel for the help, it was very, 
very usefull! :)

Looking Michel's answer and comparing my code's traces and server's log, 
I discovered what was my problem, and, unfortunally, it seems that 
really it's not the same that Alik and Rob found... In fact, it was my 
mistake, a very, very, very stupid mistake:  my url was mal formed - I 
forgot the '\n' at the end of the string readed from stdin  (I told you 
it was *very* stupid)... I'm felling like an idiot! I lost many working 
hours for that.. It's so stupid...

Anyway, I noted that, when we set the request's output format to 
"WWW_RAW", both status and content-length are often (almost always) -1, 
but I think that maybe a feature, since, in this case, libwww pass the 
server's response directly to the chunk with all headers (I think that 
libwww doesn't analize the headers in this case)...  Since I began to 
set the output format to "WWW_SOURCE" or "text/xml", it works well (of 
course, after my stupid mistake be solved)...


 In relation to the filters problem that I talked in a previous mail: 
it's gone, I don't know how... When I introduced the stdin feature (read 
the url from stdin), I rewrite my code to be more clear, and puft! the 
filter order problem gone... It still happens in the old code, but in 
the new one, it disappeared.. I supposed my old code has a bug, but I 
couldn't see exactly where...

Some answers about the Michel's suggestion :


Michel Philip wrote:

>	> For what concerns -1 status return did you tried
>	>    HTRequest_setOutputStream(request,HTBlackHole());
>
>
>Sorry,
>This is not good for the code that Alik wrote for he calls
>'HTPostFormAnchorToChunk()'
>Nor for the code that Manuele wrote for he calls 'HTLoadToChunk()'
>This was ok for me for I call 'HTLoadAbsolute()'
>
>Then maybe you could find some help with the following.
>
>For what concerns -1 content-length in a repeated request I did many
>patches.
>First are you sure that the first request really success ?
>I mean that if you do 
>    HTNet_addAfter(errors_callback, NULL, NULL, HT_ERROR, HT_FILTER_LAST);
>then errors_callback() is never called.
>
I introduced an error callback and, indeed, it is called when the status 
coded returned is -1, in my "mal formed url" situation too. In the last 
case, the error's location was in HTTPStatustream.. It seems to me that, 
when the server received the mal formed header, it supposed that my 
client was some kind of old HTTP client, returning some kind of HTTP/0.9 
compilant response (with no status line), and that appearsto be the 
cause of the stream error... It was a very good idea to introduce this 
error callback, it is very useful...

>
>Second check if -1 content-length came from HTReader_read.
>
Yes, indeed, it came from the stream call 
"(*net->readStream->isa->putblock)" in HTReader_read...

>
>I've this patch in HTReader:
>
>	    me->b_read = NETREAD(soc, me->data, INPUT_BUFFER_SIZE);
>	    if ( me->b_read < 0 ) {
>		/* mphilip@infovista.fr */
>		me->b_read = 0;
>
I applied this patch with no problems, but I didn't have enough time to 
apply the others. I'll try to do it in the next week, and after I tell 
you if it's ok for request without rawBytesCount...

[...]

>
>
>Hope this help.
>
It did help! A lot! Thanks! :)

Manuele

Received on Thursday, 31 January 2002 09:11:39 UTC