Hello!

On Mon, Mar 18, 2013 at 01:40:24AM -0400, gadh wrote:

> thanks Maxim ! i very appreciate your help on this.
> about the temp file - i protect from a response to be written to a file by
> knowing the max size that can be sent by the server and enlarging the proxy
> buffers accordingly.

You are not initializing subrequest's request_body->temp_file
pointer (among other request_body members). It might point
anywhere, and will cause problems.

> i know i ruin the original request header - its the main purpose for my code
> ! i want to issue an independant subrequest to another server, no to to the
> original. but the r->main->... is not ruined and acting ok afterwards.

Yes, indeed.

Note though, that by changing headers_in structure you are
responsible for it's consistency. It's usually much better idea
to use upstream functionality to create needed request to an
upstream instead (proxy_set_body, proxy_pass_headers and so on).

> in any case, i ask you to support this subrequest mechasnim, its obviously
> needed to send a subrequest to any server, not just to the original one, and
> also to control its response instead of just adding it to the start/end of
> page, its alot more flexible.
> can i use another mechanism in order to achive those goals ? to create a new
> upstream module ?

What is supported is subrequest in memory functionality, which
allows you to get the response in memory instead of appending it
to the response. It only works with certain upstream protocols
though. And it wasn't supposed to work at arbitrary request
processing phases, so it might be non-trivial to do things
properly, in particular - ensure subrequest consistency at early
phases of request processing and to rerun the main request once
subrequest is complete.

--
Maxim Dounin
http://nginx.org/en/donation.html

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx