Mohammad DAMT wrote:
> HANDLER:
> 0. basic communication now works. every fcgi env variable must be sent
> using one FCGI_PARAMS, hence I needed to change cgi.[c|h] API a bit.
>
> before:
> ret_t cherokee_cgi_build_basic_env (cherokee_connection_t *conn,
> cherokee_cgi_set_env_pair_t set_env_pair,
> cherokee_buffer_t *tmp,
> void *param);
>
>
> after:
> ret_t cherokee_cgi_build_basic_env (cherokee_connection_t *conn,
> cherokee_cgi_set_env_pair_t set_env_pair,
> cherokee_buffer_t *tmp,
> void *param,
> void *user_data);
>
> is that ok? one argument was added to pass user_data (fcgi handler
> in this case) to set_snv_pair callback.
I have been reading this code, but it does not make much sense for
me. It seems like you want to have an extra pointer in
set_env_pair(), but what is its purpose?
This function is meant to have two data inputs: the environment
variable name and its value. If we want to do something to build
the value, it should be outside from it..
> 1. handler now reads and process all incoming data by itself, see
> MANAGER.0
>
> 2. http header and content are now separated and handled
>
> MANAGER:
> 0. removed unused read buffer and moved the reading function to handler.
> the reason for this is that there is only one manager instance, hence
> one read buffer, so this can't be done since the read buffer is used by
> all handlers.
I'm not use at all about these changes, let me explain why I wrote
it in that way.
With FastCGI many connections can share a single connection to the
FastCGI. It multiplexes all that information in a single stream,
that is why there is IDs in the packages. The purpose of the
manager object is handle with that and demultiplex the data stream.
It keeps a lookup table updated with the connections which are
currently using the FastCGI server, so if anyone of when request the
fastcgi manager to process some input, probably it will update some
more connections on that call.
Let's speak about this and make a decision about it. This is the
basic structure of all the FastCGI support, so it has to be really
clear :-)
> Questions:
> 0. what should be returned by handler_step if:
> a. data is ready (ret_ok? or ret_eof?)
ret_eagain
> b. there is an error (ret_error?)
If it is a terminal error for the connection:
cnt->error_code = ...;
return ret_error;
> c. data is incomplete, to be retried (ret_eagain?)
If you got some data to be send, just put it on the buffer and
return ret_ok
> 1. how to print to log?
Do you want to log the connections? If so, do not do it; It should
not do it from a handler.
If what you want to write information about that FastCGI server
state or something like that, you can use:
cherokee_logger_write_string (CONN_VSRV(HANDLER_CONN(handler))->logger,
"%s", whatever);
Mohammad, thanks for your update! :-)
--
Greetings, alo.
http://www.alobbs.com
_______________________________________________
Cherokee mailing list
[email protected]
http://www.alobbs.com/cgi-bin/mailman/listinfo/cherokee
