On Thu, 2 May 2013, Giuseppe Scrivano wrote:
RFC 2606 doesn't seem very clear about it, and I can't find anywhere that
PUT/OPTIONS/ANYTHING should be handled differently than POST wrt
redirections. I don't see why suspending a PUT request would be incorrect.
Darshit, do you have any pointer?
Gijs van Tulder writes:
> Hi Darshit,
>
> Darshit Shah wrote:
>> Unless we explicitly check for opt.method = POST, this will cause a lot
>> of issues. Since the macro is being called on every redirect, even
>> HEAD/PUT/OPTIONS headers will get suspended to give way to GET. That is
>> not the beha
Hi Darshit,
Darshit Shah wrote:
> Unless we explicitly check for opt.method = POST, this will cause a lot
> of issues. Since the macro is being called on every redirect, even
> HEAD/PUT/OPTIONS headers will get suspended to give way to GET. That is
> not the behaviour we want.
Ah, I see it's mor
>
> Still, even if the sanitization is removed: I think it would be better if
> RESTORE_POST_DATA restores the previous value of opt.method, instead of
> overwriting it with a hardcoded "POST". Isn't it?
>
> As double safety yes. Maybe we should do that.
> A related question: how is a redirect re
Hi Giuseppe,
Dropping the bit that sanitizes the opt.method is probably a good idea.
(Perhaps I shouldn't have replied to your patch directly.)
Still, even if the sanitization is removed: I think it would be better
if RESTORE_POST_DATA restores the previous value of opt.method, instead
of ov
On Thu, May 2, 2013 at 12:56 AM, Gijs van Tulder wrote:
> Giuseppe Scrivano wrote:
> > what about this patch? Any comment?
>
> Another suggestion: why not save the original opt.method, set opt.method
> to NULL and put the original opt.method back later?
>
> Gijs
>
Unless we explicitly check for
hi Gijs,
Gijs van Tulder writes:
> Giuseppe Scrivano wrote:
>> what about this patch? Any comment?
>
> Another suggestion: why not save the original opt.method, set
> opt.method to NULL and put the original opt.method back later?
thanks for your suggestion but I think we should drop the code t
Giuseppe Scrivano wrote:
> what about this patch? Any comment?
Another suggestion: why not save the original opt.method, set opt.method
to NULL and put the original opt.method back later?
Gijs
diff --git a/src/retr.c b/src/retr.c
index d51b7e7..2aee578 100644
--- a/src/retr.c
+++ b/src/retr
Am Mittwoch, 1. Mai 2013 schrieb Darshit Shah:
> First, sorry for the quick and dirty hack which was the perfect example of
> how NOT to do things.
Than it was a good example ;-)
> Secondly, it lies upon me that this feature wasn't tested before submitting
> the patch. I had however relied on the
Darshit Shah writes:
> I am fixing this issue, but it is a terribly ugly hack. If someone could
> help improve it I'd be most truly grateful.
> I have a couple of ideas, but I will need to work them out and implement
> them when I have the time.
>
> The reason it has to be so ugly is that, we can
Couple of things.
First, sorry for the quick and dirty hack which was the perfect example of
how NOT to do things.
Secondly, it lies upon me that this feature wasn't tested before submitting
the patch. I had however relied on the Test Environment and since it passed
everything there, I thought it
11 matches
Mail list logo
