[mp2] $r->status does not accept a valid parameter

[su...@sbcglobal.net]

Has anyone seen this behavior?

Working on a custom WebDAV server.  Need to reply with
XML and Multi-Status response.

$r->status(Apache::HTTP_MULTI_STATUS);
or
$r->status(207);

always results in the following

Usage: Apache::Request::status(sv) at API/Modes.pm
line 235.

Regardless of the failed attempts to change status, 

	my $l = length($xml_data);
	$obj->apache_handle->set_content_length($l);
	$obj->apache_handle->content_type('text/xml');
	$obj->apache_handle->print($xml_data);
	return Apache::HTTP_MULTI_STATUS;

would always return status 200.

Tried to work around this by outputting the XML using 

$r->custom_response(Apache::HTTP_MULTI_STATUS,$xml_data);

which returned the XML data with the correct 207
response, but in this case the 

$r->content_type('text/xml');

was ignored and the server reported the xml data as
'text/html'.

Found this to be the case with both mod_perl-1.99_11
and mod_perl-1.99_12.  Did not try earlier versions.

-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] $r->status does not accept a valid parameter

[Joe Schaefer <jo...@sunstarsys.com>]

<su...@sbcglobal.net> writes:

[...]

> $r->status(Apache::HTTP_MULTI_STATUS);
> or
> $r->status(207);
> 
> always results in the following
> 
> Usage: Apache::Request::status(sv) at API/Modes.pm
> line 235.

$r->status is read-only for Apache::Request objects;
you either want

  $r->env->status(207); # env() yields Apache::RequestRec obj

or

  $r->SUPER::status(207); # Apache::RequestRec is the base
                          # class for Apache::Request (in mp2)


Not sure if this solves your overall problem,
but it should resolve this part of it.

-- 
Joe Schaefer


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] $r->status does not accept a valid parameter

[Geoffrey Young <ge...@modperlcookbook.org>]

> I've got this other thing I'm hung up on.  A response
> to an OPTIONS method should not return a content type.
>  Apache by default does not return one for this
> method.  I can't seem to find a way to disable sending
> a content-type header line.  I was hoping calling
> rflush would work, but no.
> 
> I looked at the mod_dav.c code and they noted the same
> problem in their comments.  Apparently,
> ap_send_http_header() just sends the content-type
> anyway.  Is this just a feature of the Apache libraries?

there's a separate ap_send_http_options method for handling the OPTIONS
method (as well as ap_send_http_trace for handling TRACE).

what ap_send_http_options does is create an Allow header and return OK.  one
of the few examples of this is mod_proxy, which simply calls this method
followed by ap_finalize_request_protocol.  this sends an EOS bucket, which
(I think) prevents additional headers from being added to the stream.  at
least that's what the note in send_http_options says :)

unfortunately, neither one of these methods is available to mod_perl at the
moment.  however, you might be able to fake it a bit by inserting the logic
from those calls manually in your content handler.  start with constructing
the Allow header yourself and adding it to $r->headers_out.  then, create an
eos bucket and insert it into the filter stream.  something like this (untested)

  my $bb = APR::Brigade->new($r->pool, $r->connection->bucket_alloc);
  $bb->insert_tail(APR::Bucket::eos_create($r->connection->bucket_alloc));
  $r->output_filters->pass_brigade($bb);

give it a whirl and report back if it works :)

HTH

--Geoff



-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] $r->status does not accept a valid parameter

[su...@sbcglobal.net]

Thanks guys, the
$r->env->status(Apache::HTTP_MULTI_STATUS); works
great.

I've got this other thing I'm hung up on.  A response
to an OPTIONS method should not return a content type.
 Apache by default does not return one for this
method.  I can't seem to find a way to disable sending
a content-type header line.  I was hoping calling
rflush would work, but no.

I looked at the mod_dav.c code and they noted the same
problem in their comments.  Apparently,
ap_send_http_header() just sends the content-type
anyway.  Is this just a feature of the Apache libraries?

-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [mp2] $r->status does not accept a valid parameter

[Geoffrey Young <ge...@modperlcookbook.org>]

> Regardless of the failed attempts to change status, 
> 
> 	my $l = length($xml_data);
> 	$obj->apache_handle->set_content_length($l);
> 	$obj->apache_handle->content_type('text/xml');
> 	$obj->apache_handle->print($xml_data);
> 	return Apache::HTTP_MULTI_STATUS;
> 
> would always return status 200.

besides the answer that joe gave, it looks like mod_dav itself follows this
logic

  $r->status(Apache::HTTP_MULTI_STATUS);
  $r->content_type('text/xml');
  ...
  return Apache::DONE;

which I guess makes it the sole exception for setting $r->status, which is
something that you're generally not supposed to do.

> 
> Tried to work around this by outputting the XML using 
> 
> $r->custom_response(Apache::HTTP_MULTI_STATUS,$xml_data);
> 
> which returned the XML data with the correct 207
> response, but in this case the 
> 
> $r->content_type('text/xml');
> 
> was ignored and the server reported the xml data as
> 'text/html'.

that's an apache thing, not a mod_perl thing.  as in 1.3, ErrorDocuments in
2.0 are hard-coded to content-type 'text/html' (see ap_send_error_response
in http_protocol.c).  it's come up before and I find it rather limiting and
strange, so it's probably something that would be worth looking into.

--Geoff


-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html