Darshit Shah dar...@gmail.com 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
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
hi Gijs,
Gijs van Tulder gvtul...@gmail.com 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
On Thu, May 2, 2013 at 12:56 AM, Gijs van Tulder gvtul...@gmail.com 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
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
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 response
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?
