You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Daniel Wirtz (JIRA)" <ji...@apache.org> on 2008/04/23 19:49:21 UTC
[jira] Created: (ASYNCWEB-12) AsyncWeb does not understand the
Status-Header e.g. sent by FastCGI backends.
AsyncWeb does not understand the Status-Header e.g. sent by FastCGI backends.
-----------------------------------------------------------------------------
Key: ASYNCWEB-12
URL: https://issues.apache.org/jira/browse/ASYNCWEB-12
Project: Asyncweb
Issue Type: Bug
Components: Common
Environment: AsyncWeb 0.9.0 CVS used in AsyncFCGI
Reporter: Daniel Wirtz
Priority: Trivial
When a Status header is provided, AsyncWeb does not transform it into the equivalent HTTPStatus in a HttpResponse.
A response from a FastCGI backend could look like this:
Content-Type: text/html\r\n
Status: 404\r\n
\r\n
File not found!
or
Content-Type: text/html\r\n
Status: 404 Some Custom Message\r\n
\r\n
File not found!
in PHP this looks like:
header("404: Some Custom Message"); or
header("HTTP/1.1 404 Not Found"); etc.
-> both produce the Status-Header.
As far as I know the webserver (this would be asyncweb in this case) converts the status header into the correct http status (e.g. "HTTP/1.1 404 Not Found"). I'm using PHP a lot, the status header is the default behaviour and Apache / Lighttpd handle it this way (even with mod_php instead of FastCGI). I don't want to preparse the response because of unneccessary double checking instead of simply feeding it into a HttpResponseDecoder. However, I think the status header is not part of the http specification but since it's used a lot, it would make sence.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ASYNCWEB-12) AsyncWeb does not understand the
Status-Header e.g. sent by FastCGI backends.
Posted by "Daniel Wirtz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ASYNCWEB-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592394#action_12592394 ]
Daniel Wirtz commented on ASYNCWEB-12:
--------------------------------------
No, I parse only the relevant part of the FastCGI message with the HttpResponseDecoder. FastCGI (like CGI or mod_xyz) responds besides other protocol specific stuff with a set of HTTP headers followed by the body in its "stdout"-part:
[cryptic fastcgi heading]
[stdout]
Content-Type: text/html\r\n
\r\n
Hello World!
[/stdout]
[cryptic fastcgi padding]
Except that there is no "HTTP/1.1 200 OK" or similar at the beginning it is a complete HTTP response that can be parsed by AsyncWeb - but it will contain the Status-Header if the response status has been set by the script (e.g. for redirection to a "success" uri or similar).
I also found out that it can be easily fixed from outside AsyncWeb. Cast to MutableHttpResponse, check the status header, set the http status, maybe cast back, done. However, I still think AsyncWeb should understand the status header.
> AsyncWeb does not understand the Status-Header e.g. sent by FastCGI backends.
> -----------------------------------------------------------------------------
>
> Key: ASYNCWEB-12
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-12
> Project: Asyncweb
> Issue Type: Bug
> Components: Common
> Environment: AsyncWeb 0.9.0 CVS used in AsyncFCGI
> Reporter: Daniel Wirtz
> Priority: Trivial
>
> When a Status header is provided, AsyncWeb does not transform it into the equivalent HTTPStatus in a HttpResponse.
> A response from a FastCGI backend could look like this:
> Content-Type: text/html\r\n
> Status: 404\r\n
> \r\n
> File not found!
> or
> Content-Type: text/html\r\n
> Status: 404 Some Custom Message\r\n
> \r\n
> File not found!
> in PHP this looks like:
> header("404: Some Custom Message"); or
> header("HTTP/1.1 404 Not Found"); etc.
> -> both produce the Status-Header.
> As far as I know the webserver (this would be asyncweb in this case) converts the status header into the correct http status (e.g. "HTTP/1.1 404 Not Found"). I'm using PHP a lot, the status header is the default behaviour and Apache / Lighttpd handle it this way (even with mod_php instead of FastCGI). I don't want to preparse the response because of unneccessary double checking instead of simply feeding it into a HttpResponseDecoder. However, I think the status header is not part of the http specification but since it's used a lot, it would make sence.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ASYNCWEB-12) AsyncWeb does not understand the
Status-Header e.g. sent by FastCGI backends.
Posted by "Daniel Wirtz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ASYNCWEB-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591706#action_12591706 ]
Daniel Wirtz commented on ASYNCWEB-12:
--------------------------------------
Oh sorry, of course it's
header("Status: 404 Some Custom Message");
not
header("404....");
> AsyncWeb does not understand the Status-Header e.g. sent by FastCGI backends.
> -----------------------------------------------------------------------------
>
> Key: ASYNCWEB-12
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-12
> Project: Asyncweb
> Issue Type: Bug
> Components: Common
> Environment: AsyncWeb 0.9.0 CVS used in AsyncFCGI
> Reporter: Daniel Wirtz
> Priority: Trivial
>
> When a Status header is provided, AsyncWeb does not transform it into the equivalent HTTPStatus in a HttpResponse.
> A response from a FastCGI backend could look like this:
> Content-Type: text/html\r\n
> Status: 404\r\n
> \r\n
> File not found!
> or
> Content-Type: text/html\r\n
> Status: 404 Some Custom Message\r\n
> \r\n
> File not found!
> in PHP this looks like:
> header("404: Some Custom Message"); or
> header("HTTP/1.1 404 Not Found"); etc.
> -> both produce the Status-Header.
> As far as I know the webserver (this would be asyncweb in this case) converts the status header into the correct http status (e.g. "HTTP/1.1 404 Not Found"). I'm using PHP a lot, the status header is the default behaviour and Apache / Lighttpd handle it this way (even with mod_php instead of FastCGI). I don't want to preparse the response because of unneccessary double checking instead of simply feeding it into a HttpResponseDecoder. However, I think the status header is not part of the http specification but since it's used a lot, it would make sence.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ASYNCWEB-12) AsyncWeb does not understand the
Status-Header e.g. sent by FastCGI backends.
Posted by "Julien Vermillard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ASYNCWEB-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592296#action_12592296 ]
Julien Vermillard commented on ASYNCWEB-12:
-------------------------------------------
To make things clear : you parse this fast-cgi reply message with the HttpRequestDecoder ?
Is it a usual http server behaviour ? Perhaps lighthttpd/apache parse it only when receiving from fast cgi backend ?
> AsyncWeb does not understand the Status-Header e.g. sent by FastCGI backends.
> -----------------------------------------------------------------------------
>
> Key: ASYNCWEB-12
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-12
> Project: Asyncweb
> Issue Type: Bug
> Components: Common
> Environment: AsyncWeb 0.9.0 CVS used in AsyncFCGI
> Reporter: Daniel Wirtz
> Priority: Trivial
>
> When a Status header is provided, AsyncWeb does not transform it into the equivalent HTTPStatus in a HttpResponse.
> A response from a FastCGI backend could look like this:
> Content-Type: text/html\r\n
> Status: 404\r\n
> \r\n
> File not found!
> or
> Content-Type: text/html\r\n
> Status: 404 Some Custom Message\r\n
> \r\n
> File not found!
> in PHP this looks like:
> header("404: Some Custom Message"); or
> header("HTTP/1.1 404 Not Found"); etc.
> -> both produce the Status-Header.
> As far as I know the webserver (this would be asyncweb in this case) converts the status header into the correct http status (e.g. "HTTP/1.1 404 Not Found"). I'm using PHP a lot, the status header is the default behaviour and Apache / Lighttpd handle it this way (even with mod_php instead of FastCGI). I don't want to preparse the response because of unneccessary double checking instead of simply feeding it into a HttpResponseDecoder. However, I think the status header is not part of the http specification but since it's used a lot, it would make sence.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ASYNCWEB-12) AsyncWeb does not understand the
Status-Header e.g. sent by FastCGI backends.
Posted by "Sangjin Lee (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ASYNCWEB-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593495#action_12593495 ]
Sangjin Lee commented on ASYNCWEB-12:
-------------------------------------
Maybe I didn't fully understand how fastcgi works or what this issue is about, but strictly speaking, the aforementioned response is not a response that conforms to the HTTP RFC (2616), no? AFAIK, an HTTP response that does not have a properly formatted status line is not a valid response... I'm curious, do browsers (IE, Firefox, ...) understand and accept such responses?
My concern is, yes we could change the HttpResponseDecoder so that it recognizes the status header (this doesn't seem to be part of the RFC either) and recognize it as the status even if the status line is not formed, but that would deviate from the RFC, and the same class would be used in parsing responses that are coming over the wire...
Am I misunderstanding what's being requested?
> AsyncWeb does not understand the Status-Header e.g. sent by FastCGI backends.
> -----------------------------------------------------------------------------
>
> Key: ASYNCWEB-12
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-12
> Project: Asyncweb
> Issue Type: Bug
> Components: Common
> Environment: AsyncWeb 0.9.0 CVS used in AsyncFCGI
> Reporter: Daniel Wirtz
> Priority: Trivial
>
> When a Status header is provided, AsyncWeb does not transform it into the equivalent HTTPStatus in a HttpResponse.
> A response from a FastCGI backend could look like this:
> Content-Type: text/html\r\n
> Status: 404\r\n
> \r\n
> File not found!
> or
> Content-Type: text/html\r\n
> Status: 404 Some Custom Message\r\n
> \r\n
> File not found!
> in PHP this looks like:
> header("404: Some Custom Message"); or
> header("HTTP/1.1 404 Not Found"); etc.
> -> both produce the Status-Header.
> As far as I know the webserver (this would be asyncweb in this case) converts the status header into the correct http status (e.g. "HTTP/1.1 404 Not Found"). I'm using PHP a lot, the status header is the default behaviour and Apache / Lighttpd handle it this way (even with mod_php instead of FastCGI). I don't want to preparse the response because of unneccessary double checking instead of simply feeding it into a HttpResponseDecoder. However, I think the status header is not part of the http specification but since it's used a lot, it would make sence.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ASYNCWEB-12) AsyncWeb does not understand the
Status-Header e.g. sent by FastCGI backends.
Posted by "Daniel Wirtz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ASYNCWEB-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Wirtz resolved ASYNCWEB-12.
----------------------------------
Resolution: Won't Fix
Of course the response is not valid ootb but when prepending a "HTTP/1.1 200 OK" line on top of it, the FastCGI response becomes a valid HTTP response that can be parsed by asyncweb. I did not know that the status-header is such a non-standard behaviour but as I already said, I found out that it is easy to work around the status header by casting to a MutableHttpResponse and setting the status from the status header on my own. Sorry, no fix required then.
> AsyncWeb does not understand the Status-Header e.g. sent by FastCGI backends.
> -----------------------------------------------------------------------------
>
> Key: ASYNCWEB-12
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-12
> Project: Asyncweb
> Issue Type: Bug
> Components: Common
> Environment: AsyncWeb 0.9.0 CVS used in AsyncFCGI
> Reporter: Daniel Wirtz
> Priority: Trivial
>
> When a Status header is provided, AsyncWeb does not transform it into the equivalent HTTPStatus in a HttpResponse.
> A response from a FastCGI backend could look like this:
> Content-Type: text/html\r\n
> Status: 404\r\n
> \r\n
> File not found!
> or
> Content-Type: text/html\r\n
> Status: 404 Some Custom Message\r\n
> \r\n
> File not found!
> in PHP this looks like:
> header("404: Some Custom Message"); or
> header("HTTP/1.1 404 Not Found"); etc.
> -> both produce the Status-Header.
> As far as I know the webserver (this would be asyncweb in this case) converts the status header into the correct http status (e.g. "HTTP/1.1 404 Not Found"). I'm using PHP a lot, the status header is the default behaviour and Apache / Lighttpd handle it this way (even with mod_php instead of FastCGI). I don't want to preparse the response because of unneccessary double checking instead of simply feeding it into a HttpResponseDecoder. However, I think the status header is not part of the http specification but since it's used a lot, it would make sence.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (ASYNCWEB-12) AsyncWeb does not understand the
Status-Header e.g. sent by FastCGI backends.
Posted by "Julien Vermillard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ASYNCWEB-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julien Vermillard closed ASYNCWEB-12.
-------------------------------------
> AsyncWeb does not understand the Status-Header e.g. sent by FastCGI backends.
> -----------------------------------------------------------------------------
>
> Key: ASYNCWEB-12
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-12
> Project: Asyncweb
> Issue Type: Bug
> Components: Common
> Environment: AsyncWeb 0.9.0 CVS used in AsyncFCGI
> Reporter: Daniel Wirtz
> Priority: Trivial
>
> When a Status header is provided, AsyncWeb does not transform it into the equivalent HTTPStatus in a HttpResponse.
> A response from a FastCGI backend could look like this:
> Content-Type: text/html\r\n
> Status: 404\r\n
> \r\n
> File not found!
> or
> Content-Type: text/html\r\n
> Status: 404 Some Custom Message\r\n
> \r\n
> File not found!
> in PHP this looks like:
> header("404: Some Custom Message"); or
> header("HTTP/1.1 404 Not Found"); etc.
> -> both produce the Status-Header.
> As far as I know the webserver (this would be asyncweb in this case) converts the status header into the correct http status (e.g. "HTTP/1.1 404 Not Found"). I'm using PHP a lot, the status header is the default behaviour and Apache / Lighttpd handle it this way (even with mod_php instead of FastCGI). I don't want to preparse the response because of unneccessary double checking instead of simply feeding it into a HttpResponseDecoder. However, I think the status header is not part of the http specification but since it's used a lot, it would make sence.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.