My only problem with this patch is that I don't like API's which pass
around structs. I always find it cumbersome to have to create and fill the
struct and then pass it.
Can you think of something similar without using structs?
Andi
At 01:44 PM 6/30/2002 +0200, Sascha Schumann wrote:
> I think it is time for deprecating sapi_add_header* in favor
> of a more general function, called sapi_header_op.
>
> Let me quickly recapitulate the history.
>
> The original function sapi_add_header added and sometimes
> replaced HTTP headers and changed HTTP response codes at
> will. This was still a real black box.
>
> Then I added a parameter "replace" which turned the black box
> into something more deterministic. The new function was
> called sapi_add_header_ex to retain source code
> compatibility.
>
> The recent extension for specifying the HTTP response code
> eliminated further black box symptoms, but at the cost of
> changing an established API.
>
> I therefore propose the addition of a saner sapi_header_op()
> and the removal of the API breaking change from a week ago.
> This will allow further extensions regarding parameters
> without the burden of creating new APIs at the same time.
>
> The appended patch also unbreaks the CGI SAPI which did not
> generate status codes at all -- http_status_line was NULL all
> the time.
>
>
>typedef struct {
> char *line; /* If you allocated this, you need to free it yourself */
> uint line_len;
> long response_code; /* long due to zend_parse_parameters compatibility */
>} sapi_header_line;
>
>typedef enum { /* Parameter: */
> SAPI_HEADER_REPLACE, /* sapi_header_line* */
> SAPI_HEADER_ADD, /* sapi_header_line* */
> SAPI_HEADER_SET_STATUS /* int */
>} sapi_header_op_enum;
>
>SAPI_API int sapi_header_op(sapi_header_op_enum op, void *arg TSRMLS_DC);
>
>
> - Sascha
>
>--
>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
