Re: FastCGI protocol and http headers

 

 

 

I'm writing my own FastCGI server and because of that, I'm going deep on the
protocol specs. The server is already OK. It communicates and processes
transactions normally. However, I'm now needing more sophisticated things...



[Jason Peter Sage] I have found in my REGULAR CGI programming that I have
much more flexibility and control making my own headers and using what is
known as NON-PARSED HEADER CGI. This is done by simply naming your CGI
application something like nph-myprogram   versus   myprogram.

 

Additionally, this MIGHT already work in FAST CGI as well. This MIGHT in
theory, tell the WEBSERVER (if it thinks fastcgi is in fact cgi) to NOT
parse the headers at all just from the filename.

 

I do not KNOW the answer - but - I DO know I like working with nph- (non
parsed header) CGI - as it gives me complete control of what gets sent OUT,
and as for what comes in, well.. the web server is expected (in CGI any way
as far as I know) is given the job of taking the incoming header and data
and creating that wonderful CGI environment for us. and it sets up that
temporary stream for reading in posts as well in the case of a post versus
get form method.

 

Note also - I only have experience with http url form encoded applications
(or whatever its called) HTML, HTML FORMS, and spitting out HTML back to the
client :-)

 

The FastCGI specification does not seem to offer a special handling for the
http headers. Sometimes the application may need to set up special http
headers or at least to have more control over them and, I'd like how is the
official approach for doing that. 

[Jason Peter Sage] You might find the same here is true for FAST CGI. It may
possibly grab the incoming headers and make the data available via its API,
and then going out - well - back to what I wrote above.



Should I send the http headers via a special record type ? Guess not. There
is no such a record type. Should I send it as part of the FCGI_STDOUT record
? If so, how the http server is supposed to parse it ? What's the rule ?
Hope the answer is "there is no rule" !

Follow some situations where we may need special http headers :

*         The application (script) wants to issue a HTTP 302 status
(redirection)

[Jason Peter Sage] This is EXACTLY why I like using non-parsed headers. Its
easy to do this raw. REALLY EASY. I have sample "snips" and code fragments
that are simple to understand. after all - they are simply a few text lines
that have a few keywords and specific time formats and stuff. Not difficult
to write to. Additionally, maybe I'm lazy, but I only had to write 3 headers
SO FAR: Redirect=1, Plain Text #2, HTML (With or without Cookies) #3 

*         The application wants a special content-type setting

[Jason Peter Sage] I only support ONE so far.. that long name.. something
like xxx-decode-http/form embedded/application http   or SOMETHING long and
cryptic that means - HTML support, with forms both POST and GET.  NOW I DO
NOT know how to hand fancy CGI invoked file transfers yet, which I wish I
did - then I could dispatch Pictures, ZIP files etc or at LEAST accept the
uploads of files. That I can't do yet.

*         The application needs to stuff a customized Pragma http header

[Jason Peter Sage] This I wish I knew what you were talking about. I don't
even know what pragma means. yup I admit it! :-) Sounds scary though.

Thanks in advance 4 your support !

[Jason Peter Sage] I wish I had more information to offer - . well I kind of
do - the header formats and some code snips. Just ask!

BTW - You know who I am and I KNOW you have done a wonderful job so far and
have made a lot of progress in a short amount of time!!!! GREAT JOB!

 

Jason






-- 
Obrigado,
----------------------------------------------------------------------------
--
                Jose Adriano Baltieri - Analista de Sistemas
                DTI - CENTRO - UNIMEP - Universidade Metodista de Piracicaba
                PIRACICABA - SP - Brasil - Fone : (19) 3124-1858
----------------------------------------------------------------------------
--

___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/