Yes, a clean way to force the response code would be good. You can
currently do that by sending a header('HTTP/...') but a
header('location...') call overrides this and forces a 302. I think an
optional argument to the header function that forces a specific response
code would probably be the best approach. It does of course let the user
shoot himself in the foot with bogus combinations of response headers and
codes, but that can't really be helped.
-Rasmus
On Thu, 20 Jun 2002, Chris Shiflett wrote:
> A topic was brought up on PHP general that the "Location" header should
> change the HTTP response code to 304 rather than 302. Rasmus suggested
> that this person submit a patch, and that it would be considered.
>
> I decided to look into this a bit more.
>
> A 302 response code seems more appropriate as a "default" response code
> to use when a user uses the "Location" header in some PHP code. However,
> even though it is commonly used in code handling a POST request (to
> avoid a reload=repost situation), the specification says that a response
> of 302 to any method other than GET or HEAD must *not* automatically
> redirect the user. Most browsers that I know of deliberately violate
> this, as I know several open source projects that make use of the
> redirect behavior after a POST.
>
> After reviewing the other 300-level responses, it seems that the
> definition and the implementations are rarely in synchronization. Thus,
> what would others think of adding a way for PHP developers to specify
> their own HTTP response code? I don't think this is currently possible,
> though if it is, you can ignore everything I've said. :)
>
> This could be allowed as an additional (optional) parameter of the
> header() function, or it could be a separate function. Rather than try
> to enforce the HTTP specification through the PHP engine itself (such as
> making sure the required headers of certain response codes are included
> in the response), the responsibility of generating a correct and proper
> response would be the developer's.
>
> Yes, this could have the unfortunate side-effect of poor developers
> carelessly using this feature and rendering parts of their applications
> useless on some browsers, but it would allow advanced developers even
> more control over the HTTP response. After all, that response is what
> developers are most interested in, so why not give them all the control
> over it that we can?
>
> Just an idea. I would, of course, volunteer my time to the development
> of this if it sounds like a good idea.
>
> Chris
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
