Error handlers need to access more information

[GoogleCodeExporter]

http://www.cherokee-project.com/archive/2005-May/000673.html

As was requested several years ago, there is a serious missing feature in
Cherokee. When someone specifies the custom error documents (CGI), the
'original' filename cannot be resolved anymore.

Cherokee should add the following envirionment variables to solve the
issue:

   * REDIRECT_URL: the URL-path that was not found. If a user asks for
the nonexistent page http://www.example.com/lunch/pastrami.html, for
example, this variable is set to /lunch/pastrami.html.

   * REDIRECT_STATUS: the HTTP response status resulting from the request
for the original page. In our case, this is always "404". You can use
ErrorDocument with other status codes, though, so if you have one
error-handling page for multiple statuses, you can use this variable to
determine which error status caused the error-handling page to be loaded.

   * REDIRECT_ERROR_NOTES: a brief description of what went wrong, for
example, "File does not exist:
/usr/local/apache/docroot/lunch/pastrami.html".

   * REDIRECT_REQUEST_METHOD: the method of the request for the original
page, such as GET or POST.

Now there is a 'cherokee_handler_cgi_add_env_pair', but I guess that this
will not affect the handler_error_redir which is used for the Error
Documents. So I guess there should be something in the style of
handler_error which a cgi execute method. (I guess a mash up like handler
phpcgi.)

Original issue reported on code.google.com by alobbs on 12 Apr 2008 at 10:12

[GoogleCodeExporter]

REDIRECT_URL; is supported in the patch in the other bug if redirection is set.

Original comment by ste...@konink.de on 31 Oct 2008 at 1:23

• Changed state: Started

[GoogleCodeExporter]

Working on it.

Original comment by ste...@konink.de on 31 Oct 2008 at 4:21

• Added labels: OpSys-All, Usability

[GoogleCodeExporter]

Alvaro,

If you can bump the configuration format again, hence I would like to have the 
show
variable also in the handler_error_redir. Then the attached patch will take 
care of
your environment troubles :)

Original comment by ste...@konink.de on 31 Oct 2008 at 5:36

• Changed state: Accepted

Attachments:

• redirection.diff

[GoogleCodeExporter]

The new pieces of the patch looks alright, although I'd suggest you to split it 
in parts for the next time.

I mean, the patch you have just submitted is a mix of three different bug fixes 
(one of which has been already 
applied upstream).  Please, from now on, try attach each independent patches to 
individual bugs; in that way it's 
much easier to review and discuss if needed.

Anyway, the patch looks good. It doesn't apply to trunk, so I'm doing the 
modification it by hand.
Good job!!! :-)

Original comment by alobbs on 31 Oct 2008 at 6:04

[GoogleCodeExporter]

The problem was I didn't know if the other stuff was already done... but indeed 
I
should have checked it out subversion before starting.

Original comment by ste...@konink.de on 31 Oct 2008 at 6:12

[GoogleCodeExporter]

r2272 has implemented SERVER_ADDR.

Original comment by alobbs on 31 Oct 2008 at 6:53

[GoogleCodeExporter]

r2274 added SERVER_PORT.

Original comment by alobbs on 31 Oct 2008 at 7:27

[GoogleCodeExporter]

Good job guys! :)

Original comment by skar...@gmail.com on 31 Oct 2008 at 7:42

[GoogleCodeExporter]

r2275 added REMOTE_PORT.

Anyway, do not lose the focus.. We haven't implemented the variables described 
in the bug report yet. :-)

Original comment by alobbs on 31 Oct 2008 at 7:51

[GoogleCodeExporter]

Except for 'REDIRECT_ERROR_NOTES' everything that was reported + SERVERT_PORT 
fix was
implemented.

Original comment by ste...@konink.de on 31 Oct 2008 at 7:59

[GoogleCodeExporter]

This patch basically updates the previous one, less code. But I'm still 
breaking my
head around the respinning of the error message.

Alvaro; how should I go from phase_init -> phase_setup_connection?

Original comment by ste...@konink.de on 1 Nov 2008 at 5:31

Attachments:

• redirection.diff

[GoogleCodeExporter]

Mental note;
                        cherokee_buffer_clean (&conn->web_directory);

                        cherokee_buffer_add_buffer (&conn->request_original,
&conn->request);
                        conn->redirect_method = conn->header.method;
                        cherokee_buffer_add_buffer (&conn->request, &entry->url);

instead of _init.

Original comment by ste...@konink.de on 1 Nov 2008 at 6:20

[GoogleCodeExporter]

This is probably going to be a tricky bug to fix.. I'll try to give you a hand 
as soon as I can

Original comment by alobbs on 1 Nov 2008 at 1:10

[GoogleCodeExporter]

Request to: http://localhost/

    [SERVER_PORT] => 80
    [SERVER_ADDR] => ::

Original comment by skar...@gmail.com on 2 Nov 2008 at 11:49

[GoogleCodeExporter]

Sounds very much like IPv6 :)

Original comment by ste...@konink.de on 2 Nov 2008 at 11:56

[GoogleCodeExporter]

Yeah, that's alright... :: is the contraction of 
0000:0000:0000:0000:0000:0000:0000:0000

Original comment by alobbs on 3 Nov 2008 at 8:31

[GoogleCodeExporter]

From Wikipedia:

Unspecified address

    * ::/128 — the address with all zero bits is called the unspecified address. This
address must never be assigned to an interface and is to be used only in 
software
before the application has learned its host's source address appropriate for a
pending connection. Routers must not forward packets with the unspecified 
address.

Link local addresses

    * ::1/128 — the loopback address is a unicast localhost address. If an
application in a host sends packets to this address, the IPv6 stack will loop 
these
packets back on the same virtual interface (corresponding to 127.0.0.1 in IPv4).

Then, SERVER_ADDR should be "::" or "::1"?.

Original comment by skar...@gmail.com on 3 Nov 2008 at 8:40

[GoogleCodeExporter]

That's a really good point, indeed.  It should be ::1 actually.

Original comment by alobbs on 3 Nov 2008 at 8:52

[GoogleCodeExporter]

Just a quick note in case someone is interested in the original link.

The mail-archives have changed slightly, and the original message should be 
available at: http://lists.octality.com/pipermail/cherokee/2005-May/000673.html

Original comment by tah...@gmail.com on 3 Nov 2008 at 1:30