bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] Segmentation fault with current development version of wg


From: Giuseppe Scrivano
Subject: Re: [Bug-wget] Segmentation fault with current development version of wget
Date: Wed, 08 May 2013 21:37:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Darshit Shah <address@hidden> writes:

>     
>     We suspend the post data only when we receive a 307, or do you
>     mean we
>     shouldn't suspend in this case too?
>     
> It's the other way round. A 307 response code is used when the server
> wishes to explicitly ask the client to not suspend. And that is also
> the current behaviour. 

true, I made some confusion with the terms :-)



> We currently suspend any method if the response code is a non 307
> redirect. That I believe is wrong. We should only be suspending the
> POST method and not others. 

It sounds good, but we must be careful also with 303.

Do you agree that the matrix for the method to use on the next request
should look this way?

         original
          method ->  POST       FOO      HEAD
response
status
 |
 \/
301                  GET        FOO    (terminate)
302                  GET        FOO    (terminate)
303                  GET        GET    (terminate)
307                  POST       FOO    (terminate)


> Well yeah. It has opened a whole lot of possibilities that we must
> keep considering. I will handle it separately for HEAD and send in a
> patch soon. However, I was thinking, that since the new --method
> command needs a lot of work specific to itself and that it may only
> increase in the future, we should handle that code separately? Maybe a
> set_method_opts() function?

we can refactor if/when we really need it, no need to overengineer the
code now.  Do you already have any of such "opts" in mind?

-- 
Giuseppe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]