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: Darshit Shah
Subject: Re: [Bug-wget] Segmentation fault with current development version of wget
Date: Tue, 7 May 2013 01:26:33 +0530

> This paragraph:
>
> "The 307 (Temporary Redirect) status code indicates that the target
>  resource resides temporarily under a different URI and the user agent
>  MUST NOT change the request method if it performs an automatic
>  redirection to that URI.  Since the redirection can change over time,
>  the client ought to continue using the original effective request URI
>  for future requests."
>
> seems to confirm that the patch from Gijs, that keeps the original
> method, is correct.
>
> I am going to clean it up and if nobody complains in a few hours, I will
> push it.
>

I spent some time reading the HTTPbis draft for the update to RFC 2616.
According to HTTPbis, ONLY the POST request should be suspended (which
again is in violation of RFC 2616 but allowed due to popular
implementation).
The PUT method should almost never be redirected, and if it is redirected
the new URI should point to the location where the resource is to be
created/updated.
As has been discussed earlier, HEAD should not even be following the
redirects.
OPTIONS/CONNECT/TRACE should not have a 3xx Response.
While DELETE *may* be redirected, the document did not mention anything
explicitly about it. From what I gauge, we should not suspend a DELETE
command upon a redirect.

Also, this reminds me, when a user specifies --method HEAD, that implies
s/he wishes to see the Response provided by the server and hence in this
case the headers should be printed in ALL outputs (quiet, verbose and
debug). Same with TRACE/OPTIONS commands since these are primarily used
when the user wishes to view the Response generated.


reply via email to

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