-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Nunninger wrote: > Hi, > > Am Freitag, 26. Februar 2010 20:34:58 schrieb Jakob Westhoff: >> James PIC wrote: >>> On Fri, Feb 26, 2010 at 4:38 PM, Thomas Nunninger <tho...@nunninger.info> > wrote: >>>> Hi, >>>> >>>> after updating some content in my application, I want to redirect with a >>>> 303 HTTP response code. If I use ezcMvcExternalRedirect it uses a very >>>> unspecific 302 code. In HTTP 1.1 you could use 301 and 307 instead of >>>> 302. >>>> >>>> The German wikipedia (http://de.wikipedia.org/wiki/HTTP-Statuscode) even >>>> states not to use the 302 redirect when redirecting to other sites >>>> because of an search engine error (URL hijacking). >>>> >>>> Finally I think, I should not patch ezcMvcExternalRedirect but extend it >>>> with semantic meanings like "content updated, show normal view", >>>> "content is available on other location" and so on. >>>> >>>> But I even need some patch like: >>>> >>>> --- response_writers/http.php (Revision 94) >>>> +++ response_writers/http.php (Arbeitskopie) >>>> @@ -73,7 +73,14 @@ >>>> // write output >>>> foreach ( $this->headers as $header => $value ) >>>> { >>>> - header( "$header: $value" ); >>>> + if ( !is_array( $value ) ) >>>> + { >>>> + header( "$header: $value" ); >>>> + } >>>> + else >>>> + { >>>> + header( "$header: {$value[0]}", true, $value[1] ); >>>> + } >>>> } >>>> // do cookies >>>> foreach ( $this->response->cookies as $cookie ) >>>> >>>> If the value of the header is an array, the second entry is the status >>>> code. Otherwise, everything behaves like before. >>>> >>>> The code seems to be a little bit hackish (because of the semantic in a >>>> simple array struct). But I don't have another idea without breaking BC. >>>> >>>> What do you think? >>> Wouldn't it be nice to add an $httpCode attribute to ezcMvcResponse >>> and use it in ezcMvcHttpResponseWriter? >> I think thats exactly what the ezcMvcResultStatusObject interface is for. >> >> The problem in your implementation is, that you assume that each used >> reponse writer (aka. protocol) does use the same errorcodes. Lets assume >> you have a response writer to send a mail. In this case the errorcode >> would need to be handled in a completely different way. > > You'd need to handle the status in some abstract way. But you are right and > such an abstraction is not really getting better. :-) The > ezcResultStatusObjects are much nicer > >> The ezcMvcResultStatusObject does allow just that. Simple implement a >> status object which signals the special case of redirection you require. >> For example you could implement a TemporaryRedirectStatusObject. This >> status object is simply attached to the ezcMvcResponse->status property. >> >> The implementation of the status object could look something like that: >> >> class TemporaryRedirectStatusObject >> implements ezcMvcResultStatusObject >> { >> public function process( ezcMvcResponseWriter $writer ) >> { >> switch( true ) >> { >> case $writer instanceof ezcMvcHttpResponseWriter: >> // Send out the 307 header here >> break; >> case $writer instanceof SomeOtherResponseWriter: >> // Handle other response of this status type here >> break; >> // ... >> } >> } >> } > > That could work. But as we have a central place of sending the headers in > HTTP > via the ezcHttpResponseWriter, I don't like the idea of sending headers at > this place.
The StatusObjects are processed before any headers are send out by the ResponseWriter. Therefore the place is ideal to send a responsecode header. But I have to agree that it is not ideal to rely on this implementation detail of the HttpResponseWritter. Nevertheless I think it is the most feasible way right now. > Because of that, I'd prefer something like my suggested patch of > the http response writer (still not convinced that it is nice to distinguish > between headers containing a string and an array...). > > Thomas > >> This way the status can be handled by different response writers in one >> place to be a lot more flexible, than confining the handling only to >> http status codes. >> >> HTH. >> >> Cheers, >> Jakob >> >> -- >> Jakob Westhoff (GPG 0xCBF7FC6A) >> http://westhoffswelt.de > > > - -- Jakob Westhoff (GPG 0xCBF7FC6A) http://westhoffswelt.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLiZZrAAoJEE0XwzzL9/xqjAcH/2QcB9b7ZRzlYfK+aIm9igpu v6quDH69gbgsiLtc0LHfe5P89wucXu+FM5yPsdyGr1Q4SshkAKpvARQwGyI6ZxDa dL/dqH9MpjlAPum+hytP1W/4LFrL71ilTF4Cnsj+SDssrvD6p/1qEfpko6D/HQXf ZQTwM8NJJYLI4IChY3F3wc9risEXEXOw/I1Pr99/TYUEiUnpqtonMBMx/HCJKW/r 8YnzPqu9i2vcSJ+F1eHXSZrCIHsgzUPQAOUR/tK8F2kWwvW4fhBWOh0DNx8L3iLU 5EBbgFOEOJRddo7sSnbmXBUtKvNACjacYwOEaEFBWZlXsA+2UeHLDA0Po/TmBiA= =KUO8 -----END PGP SIGNATURE----- -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
