I don't know what the patch implies, because I don't use git... If the
pathc is about 301 or 302 status redirects then I'd have my doubts about
the patch. If I am not mistaken this behaviour is likely to be a
violation of the HTTP specifications. A 301 or 302 redirect should not
hold it's variables for POST requests. According to the specifications a
301 and 302 should just redirect the URL and not it's variables for POST
requests. That "problem" has been solved in HTTP/1.1 through the 307
redirect, which a client should handle by resubmitting the variables. If
the patch is about 301 or 302 redirects only, it would be an issue which
should not be solved on the server side.
Regards,
Arjan
-----Oorspronkelijk bericht-----
Van: Martin Stjernholm [mailto:<mast[at]roxen.com>]
Verzonden: Saturday, January 10, 2009 6:06 PM
Aan: <roxen[at]roxen.com>
CC: Stephen R. van den Berg; <grubba[at]roxen.com>
Onderwerp: Re: Lots of patches that can be integrated into Roxen 5.0 in
a heartbeat
Continuing:
>> commit 9d5f70747761a4e28cab901e2180a1174b073e39
>> Preserve POST variables upon redirect
Did a bit different solution: Kept the POST vars in id->misc to avoid
another member in every request object, and populated it separate from
real_variables to ensure that other variables don't creep in there.
As for this bit:
@@ -2878,7 +2880,15 @@ object clone_me()
c->time = time;
c->raw_url = raw_url;
- c->real_variables = copy_value( real_variables );
+ mapping nf=([]);
+ if(RXML_CONTEXT)
+ { mapping form=RXML_CONTEXT->get_scope ("form");
+ foreach(indices(form),string idx)
+ { mixed t=form[idx];
+ nf+=([idx:arrayp(t)?t:()]);
+ }
+ }
+ c->real_variables = nf;
c->variables = FakedVariables( c->real_variables );
c->misc = copy_value( misc );
c->misc->orig = t;
I think this is wrong since it can cause variables to "bleed over" if
a subrequest is made inside an essentually unrelated rxml parse
session. If the subrequest is related then the form scope would be
synched with real_variables already (in fact, the form scope is an
object wrapper that accesses the same real_variables mapping, so the
above only becomes a very convoluted mapping copy).
And besides, it doesn't look to me that it's necessary for the
redirect thingy to work. Am I wrong?
Btw, a side note on:
nf+=([idx:arrayp(t)?t:()]);
I've seen this way of adding elements to mappings curiously often.
Pike can - under favorable conditions - optimize it to a destructive
operation on the first mapping so the whole thing isn't copied. But
sometimes it might not do that, and I'm also not sure if it can
optimize away the creation of the small mapping. But anyway, to avoid
such worries, why not just use a mapping assignment?
nf[idx] = arrayp(t)?t:();
It's shorter too. :)
>> commit f91d0e08d845fd9c47fae961333d1fe47d16c7b1
>> Prevent spurious connection resets due to async sockets
Too dangerous. That could make close() block on tls connections, and
it mustn't block there. Need an analysis of the problem to decide on
how to get this right.
I don't understand your comment either.
>> commit 362e25ea53b7569250da884daab0d7b7ae58941c
>> Differentiate cache keys for different hosts mapped to the
default server
Looks like the change in roxen.pike is unrelated. Disregarding it.
The pragma["no-cache"] test added in
- if(misc->cacheable && !misc->no_proto_cache &&
- (cv = conf->datacache->get(raw_url, this_object())) )
+ if(misc->cacheable && !misc->no_proto_cache && !pragma["no-cache"]
&&
+ (cv = conf->datacache->get(cache_key, this_object())) )
is also unrelated afaics. Please motivate it separately.
As for the rest of it, I implemented it another way which should work
better with the config resolution procedure. Please test.
The rest still on the to-do..
__________________________________________________________
Deze e-mail en de inhoud is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde(n). Indien u niet de geadresseerde bent van deze e-mail verzoeken
wij u dit direct door te geven aan de verzender door middel van een reply e-mail
en de ontvangen e-mail uit uw systemen te verwijderen. Als u geen geadresseerde
bent, is het niet toegestaan om kennis te nemen van de inhoud, deze te kopieren,
te verspreiden, bekend te maken aan derden noch anderszins te gebruiken.
The information contained in this e-mail is confidential and may be legally
privileged. It is intended solely for the addressee. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken or omitted
to be taken in reliance on it, is prohibited and may be unlawful. Please notify
us immediately if you have received it in error by reply e-mail and then delete
this message from your system.
__________________________________________________________
|