Re: sapi_header_op

Yes, probably a good idea. On Sun, 30 Jun 2002, 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 >