On Mon, 8 Apr 2002, Jacky Lam wrote:

> Ha. I am surrendered. You are really great to maintain those code.
> After I add some codes, it will be easily break the others. But I still
> think that libcurl should be able to handle some poor servers. Here is the
> patch to transfer.c which seems have no side effect up to now I have been
> tested. But it is not the clever patch you want I think.

Remember that I wrote the code in the first place, and that I've lived with
this code for more than four years, it's grown with me! :-) I think you've
showed a very good insight in how it works and even if I've edited your
patches slightly, they've been very valuable additions.

> What do you thnk about the patch? Will it introduce some undesired
> behaviours?

No, I think that will work.

However, I think I came up with a simpler approach (based on your fix) that
I'd like you to try. As we already check for code '304' on one spot in the
code, I thought we could take advantage of that fact so that we don't have to
do it twice for the same status code.

There's an additional advantage to this approach: it works with 204 as
well... :-)

diff -u -r1.89 transfer.c
--- lib/transfer.c 4 Apr 2002 12:19:56 -0000 1.89
+++ lib/transfer.c 8 Apr 2002 07:06:04 -0000
@@ -366,15 +366,12 @@
                    reading! */
                 if(-1 != conn->size)
                   conn->maxdownload = conn->size;
-
- /* If max download size is *zero* (nothing) we already
- have nothing and can safely return ok now! */
- if(0 == conn->maxdownload)
- stop_reading = TRUE;
-
- /* What to do if the size is *not* known? */
               }
-
+ /* If max download size is *zero* (nothing) we already
+ have nothing and can safely return ok now! */
+ if(0 == conn->maxdownload)
+ stop_reading = TRUE;
+
               if(stop_reading) {
                 /* we make sure that this socket isn't read more now */
                 k->keepon &= ~KEEP_READ;

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/