Geoffrey Young wrote:

Stas Bekman wrote:

Currently, $r->send_http_header can't be called before the response stage, so the 1.0 code won't run out of the box. This is an attempt to solve that problem.

I haven't committed it, because I'm not sure whether the following assumption will stand:

- wb->header_parse = MpDirPARSE_HEADERS(dcfg) ? 1 : 0;
+ wb->header_parse = (!r->content_type && MpDirPARSE_HEADERS(dcfg)) ? 1 :

can you explain what's going on here? I see that you've made compat.pm's send_http_header() almost a no-op, which looks just fine to me. I would have thought that was sufficient.

so, what is all the rest of this? can't 2.0 users just rely on the header filter to do the work? if 2.0 users call send_http_header() when they shouldn't, shouldn't we just throw an error instead of appeasing improper use of the API?

or are you talking about legacy 1.0 code running without compat.pm? I guess I don't get what's going on here (not that I have to :)
Yes, I'm talking about exactly that. We should turn the headers parsing off, if 1.0 code has called send_http_header.

We actually need the same functionality for 2.0. Because what happens if there are two registry scripts running from the same location which is configured to parse headers? If the script doesn't send headers in plain text, the script would have failed. I haven't realized that I've already fixed that while writing a bunch of test scripts for ModPerl::Registry. I did this testing already at a later stage in:

MP_INLINE apr_status_t modperl_wbucket_pass(modperl_wbucket_t *wb,
const char *buf, apr_size_t len)
{
[...]

if (wb->header_parse && !wb->r->content_type) {
/* parse headers */
[...]

so that solution is needed for both 1.0 and 2.0.

Therefore I go ahead and make send_http_header a NOOP + $r->content_type if it passes the type. And in the future we will probably see if my solution stands or not.


__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to