unsubscribe
On Wed, Feb 4, 2015 at 1:42 AM, Scott Lo joba62r...@gmail.com wrote: -- Best Regards, Scott Lo -- [image: --] Nico Coetzee [image: http://]about.me/nico.coetzee http://about.me/nico.coetzee?promo=email_sig
Re: Fwd: All responses are 200 (server error)
$r-status(400); $r-status_line(400 Error Baby); Produces: HTTP/1.1 400 Error Baby And $r-status(207); $r-status_line(207 Multi-Status); Produces: HTTP/1.1 207 Multi-Status So, I recon I will try this now in the main app. Thanks :-) On Tue, Sep 28, 2010 at 8:26 AM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On 9/28/2010 12:25 AM, Nico Coetzee wrote: The status 400 (with $r-status_line) produces the same result HTTP/1.1 200 OK and with ($r-status) is creates a HTTP/1.1 400 Bad Request (the custom string gets lost) The $r-status with a code of 499 produces a HTTP/1.1 400 Bad Request Sort of confirms my theory. Set status to 400 and set status_line to 400 Custom Message, see what happens? I suspect that 499 simply isn't allowed, which is wrong, but the current behavior none the less.
Re: Fwd: All responses are 200 (server error)
and... it works now !! On Tue, Sep 28, 2010 at 8:30 AM, Nico Coetzee nicc...@gmail.com wrote: $r-status(400); $r-status_line(400 Error Baby); Produces: HTTP/1.1 400 Error Baby And $r-status(207); $r-status_line(207 Multi-Status); Produces: HTTP/1.1 207 Multi-Status So, I recon I will try this now in the main app. Thanks :-) On Tue, Sep 28, 2010 at 8:26 AM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On 9/28/2010 12:25 AM, Nico Coetzee wrote: The status 400 (with $r-status_line) produces the same result HTTP/1.1 200 OK and with ($r-status) is creates a HTTP/1.1 400 Bad Request (the custom string gets lost) The $r-status with a code of 499 produces a HTTP/1.1 400 Bad Request Sort of confirms my theory. Set status to 400 and set status_line to 400 Custom Message, see what happens? I suspect that 499 simply isn't allowed, which is wrong, but the current behavior none the less.
All responses are 200 (server error)
Hi - don't know if anybody else have come across this. I have a mod_perl instance that produces output just as it should (checked in the logs and I even written the output to file just to have an extra check). The tcpdump also show everything is ok. BUT The content has the following HTML appended at the end: !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title200 OK/title /headbody h1OK/h1 pThe server encountered an internal error or misconfiguration and was unable to complete your request./p pPlease contact the server administrator, webmas...@host.example.com and inform them of the time the error occurred, and anything you might have done that may have caused the error./p pMore information about this error may be available in the server error log./p hr addressApache/2.2.3 (CentOS) Server at webdavtest Port 81/address /body/html So, I've enabled debug level logging everywhere and even enabled diagnostics in the mod_perl script. Nothing strange shows up anywhere. I even tried to change the return code with return Apache2::Const::XXX (XXX could be anything) but the return code is ALWAYS 200 with the above HTML appended to what ever output is sent to the browser. I also noted that the content length header is correct for the content sent to the browser and does not include the additional HTML above, but it still confuses the browser. Any ideas? Environment: CentOS 5.5 OS with the following packages: * httpd-2.2.3-43.el5.centos.3 * mod_perl-2.0.4-6.el5 In my config I have the following enabled: * LogLevel debug * PerlWarn On Thanks Nico
Fwd: All responses are 200 (server error)
Oops - seems I didn't include the group on my reply
FYI
Here is another test I did (simpler)
Apache Config
PerlModule FNBC::test_statusline
PerlWarn On
Location /test1
SetHandler perl-script
PerlResponseHandler FNBC::test_statusline
/Location
test_statusline.pm
package FNBC::test_statusline;
use strict;
use warnings;
use Apache2::Access ();
use Apache2::RequestUtil ();
use Apache2::RequestRec ();
use Apache2::Const -compile = qw( OK );
sub handler {
my $r = shift;
$r-status_line(499 We have been FooBared);
$r-err_headers_out-add( 'X-Testing' = 'True' );
$r-content_type( text/html );
my $body = htmlheadtitleTesting/title/headbodyh3It really
does work.../h3/body/html;
$r-set_content_length( length( $body ) );
$r-print( $body );
return Apache2::Const::OK;
}
1;
Trace
GET /test1/sdjakgd HTTP/1.1
Host: webdavtest:81
User-Agent: Links (2.2; Linux 2.6.32-24-generic x86_64; 210x65)
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Charset: us-ascii, ISO-8859-1, ISO-8859-2, ISO-8859-3, ISO-8859-4,
ISO-8859-5, ISO-8859-6, ISO-8859-7, ISO-8859-8, ISO-8859-9, ISO-8859-10,
ISO-8859-13, ISO-8859-14, ISO-8859-15, ISO-8859-16, windows-1250,
windows-1251, windows-1252, windows-1256, windows-1257, cp437, cp737, cp850,
cp852, cp866, x-cp866-u, x-mac, x-mac-ce, x-kam-cs, koi8-r, koi8-u, koi8-ru,
TCVN-5712, VISCII, utf-8
Accept-Language: en, *;q=0.1
Connection: Keep-Alive
HTTP/1.1 200 OK
Date: Tue, 28 Sep 2010 06:06:13 GMT
Server: Apache/2.2.3 (CentOS)
X-Testing: True
Content-Length: 92
Connection: close
Content-Type: text/html; charset=UTF-8
htmlheadtitleTesting/title/headbodyh3It really does
work.../h3/body/html
I really would like to know why I can not set the status line I followed
the example from
http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_status_line_
Thanks
Nico
Re: Fwd: All responses are 200 (server error)
The status 400 (with $r-status_line) produces the same result HTTP/1.1 200 OK and with ($r-status) is creates a HTTP/1.1 400 Bad Request (the custom string gets lost) The $r-status with a code of 499 produces a HTTP/1.1 400 Bad Request On Tue, Sep 28, 2010 at 6:31 AM, William A. Rowe Jr. wr...@rowe-clan.netwrote: Two thoughts... try status 400 (might be special handling for 4xx unknown) try r-status instead of/in addition to just r-status_line?
Help: unwanted extra characters in output
Hi - I have a problem which I can't seem to solve. I am busy implementing a webdav solution in mod_perl and as you may know, the output is XML based. The problem is that the output generated by mod_perl contains additional characters before and after the XML which the webdav clients don't seem to like. If I convert this script to a CGI, it works 100% and the extra characters is not present. Any ideas? Here is the example trace (check the 20d and 0 before and after the XML): PROPFIND /webdav/ HTTP/1.1 Host: test:81 User-Agent: cadaver/0.22.3 neon/0.25.5 Connection: TE TE: trailers Depth: 0 Content-Length: 297 Content-Type: application/xml Authorization: Basic dGVzdHVzZXIxOnBhc3N3b3Jk ?xml version=1.0 encoding=utf-8? propfind xmlns=DAV:prop getcontentlength xmlns=DAV:/ getlastmodified xmlns=DAV:/ executable xmlns=http://apache.org/dav/props// resourcetype xmlns=DAV:/ checked-in xmlns=DAV:/ checked-out xmlns=DAV:/ /prop/propfind HTTP/1.1 200 OK Date: Wed, 22 Sep 2010 04:25:57 GMT Server: Apache/2.2.3 (CentOS) Cache-Control: max-age=0 Expires: Wed, 22 Sep 2010 04:25:57 GMT Connection: close Transfer-Encoding: chunked Content-Type: text/xtml; charset=utf-8 20d ?xml version=1.0 encoding=utf-8? D:multistatus xmlns:D=DAV:D:response xmlns:lp1=DAV: xmlns:lp2=http://apache.org/dav/props/; D:href/D:hrefD:propstatD:prop lp1:resourcetypeD:collection//lp1:resourcetype lp1:getlastmodified2010-09-14T05:09:29Z/lp1:getlastmodified lp1:executableF/lp1:executable lp1:getcontentlength4096/lp1:getcontentlength D:checked-in / D:checked-out / D:lockdiscovery/ /D:prop D:statusHTTP/1.1 200 OK/D:status /D:propstat /D:response /D:multistatus 0
