Re: [Components] MvcTools: specialized HTTP response codes
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. 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
--
Thomas Nunninger
Steinhalde 108
79117 Freiburg
Tel.: +49 761 1201850
Mobil: +49 163 7115153
http://nunninger.info
USt-IdNr: DE259832548
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] MvcTools: specialized HTTP response codes
-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
[Components] MvcTools: specialized HTTP response codes
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?
Have a nice weekend
Thomas
--
Thomas Nunninger
Steinhalde 108
79117 Freiburg
Tel.: +49 761 1201850
Mobil: +49 163 7115153
http://nunninger.info
USt-IdNr: DE259832548
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] MvcTools: specialized HTTP response codes
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?
Regards
--
http://jamespic.com/contact
Customer is king - Le client est roi - El cliente es rei.
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] MvcTools: specialized HTTP response codes
Am Freitag, 26. Februar 2010 16:45:05 schrieb James PIC:
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?
Hm, that could work (but don't know if it's nice): Send the response code with
the first header sent.
Thomas
Regards
--
http://jamespic.com/contact
Customer is king - Le client est roi - El cliente es rei.
--
Thomas Nunninger
Steinhalde 108
79117 Freiburg
Tel.: +49 761 1201850
Mobil: +49 163 7115153
http://nunninger.info
USt-IdNr: DE259832548
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] MvcTools: specialized HTTP response codes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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.
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;
// ...
}
}
}
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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEcBAEBAgAGBQJLiCJgAAoJEE0XwzzL9/xqa1UIAMN3kpG6QBgRuVNYVra0do9A
5xXpowJELerztYVBIBFFt9AzWV8cgVoXs0LpzKpWfokz9X7BP6MF2WhWHkE/K1+k
Wkzxk0+yapGQRgrw/p0qP8HhWo1xNR1s+lkbi3jkdwiyzmK+jeFTcHUdgOgBt1YY
MlzVU+mN++LfGyU/0tTEXbUKc+hehhEXy7c+nbTRCxYgCprJunbDiZVZIO8vyNb3
sSSHqbzHfC9VsW+y5YDFdO+WxiTufAZHQdvY3QveOyLXpLmcIvxX6lJ+XjRxyV+h
ULensy8YnXztXMLGCdn3ew8iiFUMsbwRgT90qGBfsx0Soa4wrYYoMKK4KGTgPvA=
=dJub
-END PGP SIGNATURE-
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
