RE: Problems with data POST with Timeout

Manoj wrote:
> Since you  guys worked on this problem, could you please provide your
inputs.
> Any inputs would be greatly appreciated.

The answer had yet been clearly gave by Manuele
in his (her?) previous answer.

Call

     HTRequest_setOutputFormat(request, WWW_SOURCE);

rather than

      HTRequest_setOutputFormat(request, WWW_RAW);

and then the terminate_callback will be called 
immediatly after the request is done.


/mph

Note:
However the channel will still stay openned.
It could be used by other requests to the same host
until the sever close it or the lib close it.
(looks for  'idle' and 'gotten cold' in HTHost.c)



mnautiyal@hss.hns.com on 01/25/2002 11:25:15 AM

To:   Manuele Kirsch Pinheiro <Manuele.Kirsch_Pinheiro@inrialpes.fr>,
      "'alik@witesite.com'" <alik@witesite.com>, Michel Philip
      <mphilip@infovista.com>
cc:   "'www-lib@w3.org'" <www-lib@w3.org> (bcc: Manoj Nautiyal/HSS)

Subject:  Problems with data POST with Timeout







Hi All,

I'm writing a client application  to  post an XML document to a servlet (on
a
JigSaw server).
I used Alik's code as it is, and just added following line:

/* timeout of 10 secs...*/
HTHost_setEventTimeout(10000);

I got  response as an XML doc:
------------------------------------------------
Looking up shikhar
Looking up shikhar
Contacting shikhar
Writing 1Kbytes
Writing 1Kbytes
Reading...
Request timeout - server did not respond.
Fatal Error: Server timed out
In terminate handler...
---Printing response---->HTTP/1.1 200 OK
Date: Fri, 25 Jan 2002 06:08:29 GMT
Transfer-Encoding: chunked
Content-Type: text/html
Server: Jigsaw/2.2.0

18D
<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE pap PUBLIC '-//WAPFORUM//DTD PAP 2.0//EN'
'http://www.wapforum.org/DTD/pap_2.0.dtd'
[<?wap-pap-ver supported-versions="2.0,1.*"?>]>

<pap>
  <resultnotification-response push-id="push@ppg.com" code="1000" desc="The
request succeeded">
    <address address-value="WAPPUSH=+12345/type=PLMN@necppg.com" />
  </resultnotification-response>
</pap>


As in the above output, I get response only after the timeout. but the
server
responds in 1-2 seconds. Even if I increase the timeout,
(say 20 seconds or more!!) I get response printed as above, only after the
timer
expires.
Can you please give an idea, whats happening and why this is so? Also how
can I
handle timeouts...say in a callback..

Also, how I can send multiple requests simultaneously and handle the
response
asynchronously, keeping in view that libwww doesn't
support requests to server on different threads.  How's this possible? This
is
very much required  wrt  performance.


Thanks in advance.
Manoj Nautiyal





Manuele Kirsch Pinheiro <Manuele.Kirsch_Pinheiro@inrialpes.fr> on 01/24/2002
10:21:28 PM

To:   Michel Philip <mphilip@infovista.com>
cc:   "'www-lib@w3.org'" <www-lib@w3.org>, "'alik@witesite.com'"
      <alik@witesite.com> (bcc: Manoj Nautiyal/HSS)

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:13:19 UTC