fcgi-proxy-dev

Checkout Tools
  • last updated 1 hour ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
No need for this extra test, so remove dangit! :)

Extend the output routine to ensure full writes

Limit environment size to FastCGI to FCGI_MAX_ENV_SIZE

(which is currently 65535)

Add support for starting multiple fastcgi processes listening on a

given socket. This somewhat makes up for our lack of a good way to

manage connections to a given proxy backend.

* support/fcgistarter.c

(main): Accept a new -N option that controls how many child procs

we fork off.

Oops, missed one thing I wanted to fix...

* support/fcgistarter.c

(main): Give the usage message if we get a bogus port argument.

Add a first cut at a fastcgi starter program. This does the appropriate

daemonization and sockets magic to let a standard fastcgi program listen

on a TCP port.

Unfortunately due to some requirements of the FastCGI libraries and the

way APR process creation works this currently requires platform specific

code and thus only works on Unix systems.

* support/fcgistarter.c: New program.

* support: Add fcgistarter to svn:ignore.

* support/Makefile.in: Build fcgistarter.

Don't just hardcode 30 seconds as the poll timeout.

* modules/proxy/mod_proxy_fcgi.c

(dispatch): Use the worker timeout for our polls, falling back to the

old behavior of 30 seconds if there is no worker timeout set.

Fix up the path info in the balancer backend just like we do in the

fcgi backend. This lets Rails apps work under a balancer setup without

any hacks to Rails itself.

* modules/proxy/mod_proxy_balancer.c

(proxy_balancer_canon): Set r->path_info based on the path we got

from parsing the URL.

* modules/proxy/mod_proxy_fcgi.c

(proxy_fcgi_canon): Remove the comment about balancer not setting

the path_info.

    • ?
    ./modules/proxy/mod_proxy_balancer.c
Stop holding open connections to the backend fastcgi processes. At

this point we lack a good way to manage them, and thus it's really

easy to end up with situations where you get weird timeouts because

other worker process are holding all the connections open.

This allows Rails applications to reliably work with mod_proxy_fcgi.

* modules/proxy/mod_proxy_fcgi.c

(dispatch): Add a timeout for our poll. This should be controlled

by a config option of some sort, but for now just hardcode it.

(proxy_fcgi_handler): Set close_on_recycle to 1, so we don't hold

open connections to the fastcgi processes.

Bring the debugging output up to date with the kind of things that are

actually being debugged at the moment. Also note a problem with the way

we handle the path info setup.

* modules/proxy/mod_proxy_fcgi.c

(proxy_fcgi_canon): Log the filename and path info when we set them,

add a note that the path info stuff isn't being set if we're run in

a balancer setup, which needs to be fixed somehow.

(send_environment): Add an (ifdefed) call to log the environment vars

we send to the backend server.

(dump_header_to_log): Default to ifdefing this out, we're a bit beyond

bugs in the raw FCGI protocol at this point and it fills up the logs.

* modules/proxy/mod_proxy_fcgi.c

(dispatch): Remove extra level of indentation.

Document that we are being chunking in our

content passing, as compared to simply spooling

all the content in until clen == 0. Also, we

need to cleanup the brigade after each pass.

OK, if we have already seen headers, it's a smashing

good idea to go ahead and pass the data along.

Minor style change: IMO checking for APR_SUCCESS is

just better and more consistant.

Now that the dispatch function handles the entire request there's no need

to create a long lived pool, we can use one that's local to the function.

* modules/proxy/mod_proxy_fcgi.c

(proxy_fcgi_baton_t): Removed.

(dispatch): Use a local setaside pool instead of one from the baton.

(proxy_fcgi_handler): Don't bother creating a baton.

Clean up the end-of-headers detection code a bit. I'm still getting some

strange problems with really large numbers of headers, but I'm starting to

suspect that it's a problem with my FastCGI lib, not this module, and this

at least makes things shorter and a bit easier to read, along with fixing

one bug.

* modules/proxy/mod_proxy_fcgi.c

(handle_headers): Get rid of some cases that were not strictly needed.

Insert a case that was missed that screwed things up when there were

more than one header.

(dispatch): Move the 'done with headers' code into the preceding block,

add a note about a case that needs to be investigated.

Update the proxy worker stats when we read/write data from/to the back

end fastcgi process.

* modules/proxy/mod_proxy_fcgi.c

(send_data, get_data): New wrapper functions that do the sendv/recv

stuff and then update the proper statistics.

(send_begin_request, send_environment, dispatch): Use send_data/get_data.

Update an old comment.

* modules/proxy/mod_proxy_fcgi.c

(proxy_fcgi_handler): Stop describing the old URL style, remove a stray

empty line.

Fix the code that detects the end of the headers in mod_proxy_fcgi. In

the old code, we'd fail to detect the end of the headers if they were split

over multiple fastcgi records, or if the cgi script used \n at the end of

each header instead of \r\n.

* modules/proxy/mod_proxy_fcgi.c

(HDR_STATE_READING_HEADERS,

HDR_STATE_GOT_CR,

HDR_STATE_GOT_CRLF,

HDR_STATE_GOT_CRLFCR,

HDR_STATE_GOT_LF,

HDR_STATE_DONE_WITH_HEADERS): Constants to track where we are in parsing

the end of the headers.

(handle_headers): Take the current parsing state as an argument, use a

state machine to detect the end of the headers instead of strstr.

(dispatch): Pass the state to handle_headers.

Change the FastCGI URL scheme to fcgi://.

* modules/proxy/mod_proxy_fcgi.c

(proxy_fcgi_canon): Stop pretending unix domain sockets will need their

own url scheme.

(FCGI_SCHEME): New constant to describe the FastCGI proxy backend.

(proxy_fcgi_handler): Drop the fcgi-local stuff, use FCGI_SCHEME now that

we aren't worrying about multiple types of FastCGI workers.

Allow for "natural" usage of normal FCGI structs when logical, yet

still correctly handle cases where we need to ship those structs

over the wire, by transforming them from FCGI structs to

unsigned char arrays. Place the logic of mapping that

struct to the arrays in distinct functions, isolating

them.

After more comparison with existing mod_proxy backends, such as http

it seems clear that we're going to need to be able to specify arbitrary

portions of the URL that need to be added to the path info. Follow the

lead of mod_proxy_http and add the calculation of this into the canon

handler.

* modules/proxy/mod_proxy_fcgi.c

(proxy_fcgi_canon): Add the path portion of the back end URL to the

path_info of the request, via the ap_proxy_canonenc function.

Set up r->path_info so that the PATH_INFO environment variable gets

passed on to the back end FastCGI process.

* modules/proxy/mod_proxy_fcgi.c

(proxy_fcgi_canon): Use the post-hostname portion of the URL as the

path info for the request.

In theory, we now correctly implement all of the FastCGI protocol, so

there's no reason that request ids wouldn't be matching up. Until we

see an example of a request id mismatch error that is absolutely not

caused by an error in our parsing of the FastCGI protocol, we should

be able to go back to treating mismatches as errors.

* modules/proxy/mod_proxy_fcgi.c

(dispatch): Remove #ifdef that turned off treating rid mismatches as

fatal errors.

Update a log message.

* modules/proxy/mod_proxy_fcgi.c

(fcgi_do_request): We're no longer just handling STDIN in this call...

Make the handling of FastCGI request headers consistent. Previously, we

used a struct to hold the data when writing it, but read it into an array

when reading it. This meant that the knowledge of the header layout was

in two places. This change moves both sides to using an array, and adds

a set of #defines for the offsets into the array, so neither side can get

out of sync.

This also moves the logic for setting up the content length bytes into one

place, where before we had it in several places.

* modules/proxy/fcgi_protocol.h

(fcgi_header): Removed.

(FCGI_HDR_VERSION_OFFSET,

FCGI_HDR_TYPE_OFFSET,

FCGI_HDR_REQUEST_ID_B1_OFFSET,

FCGI_HDR_REQUEST_ID_B0_OFFSET,

FCGI_HDR_CONTENT_LEN_B1_OFFSET,

FCGI_HDR_CONTENT_LEN_B0_OFFSET,

FCGI_HDR_PADDING_LEN_OFFSET,

FCGI_HDR_RESERVED_OFFSET): New constants.

* modules/proxy/mod_proxy_fcgi.c

(fill_in_header): Take an array, not a struct pointer, and handle all

the contents of the header, not just the type and request id.

(send_begin_request, send_environment, dispatch): Update for new way

to fill in headers.

Make a pass through mod_proxy_fcgi and clean up its style a bit. This

makes everything consistent with regard to spacing, line length, etc.

* modules/proxy/mod_proxy_fcgi.c

(dump_header_to_log, dispatch, proxy_fcgi_handler): Clean up.

Read the FCGI_STDERR stream and log it to the error log. This will need

cleanup, but at least it keeps us from messing up the stream when we get

stuff written to stderr by the fastcgi process.

* modules/proxy/mod_proxy_fcgi.c

(dispatch): Move the plen recv down after the switch, so it gets done

for all cases that have padding. Read data for the FCGI_STDERR case

just like we do for FCGI_STDOUT, but write it to the log instead of

sending it to the client.

Make sure that we read the padding bytes in all cases. Also cut

down on some of the crazy verbose logging, since this seems to be

the problem we were trying to find.

* modules/proxy/mod_proxy_fcgi.c

(dispatch): Remove really verbose logging, move reading of the

padding bytes down to the end of the FCGI_STDOUT case.

Tested By: iholsman

more debug statements.

right now it looks like for large requests it isn't reading enough off the wire.