cgi-devel Mailing List for FastCGI / CGI C++ library (Page 3)
Status: Beta
Brought to you by:
drrngrvy
Menu
▾
▴
cgi-devel — developer list
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
(2) |
Mar
(8) |
Apr
|
May
(2) |
Jun
(13) |
Jul
(7) |
Aug
(9) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(2) |
| 2011 |
Jan
(10) |
Feb
|
Mar
|
Apr
(4) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(3) |
Dec
|
| 2012 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Darren G. <lis...@go...> - 2010-07-27 00:34:45
|
Hi Richard,
On 6 July 2010 12:13, Richard Forrest <ri...@th...> wrote:
>
> Thanks for responding so quickly to my bug report yesterday.
>
Sorry about the slowness of this one! Apparently it slipped through my
inbox.
> Today I have a const correctness problem.
>
> I have a 'request' object that has been passed by const reference and
> would like to query the contents of its get, session etc.
>
> 1. data_map_proxy::count(const key_type&) is not a const member
> function. Is there any reason for that? I tried changing it to const
> without any obvious problems.
>
No reason. I've changed this to const locally.
> 2. I can use pick() to access 'get' parameters but it does not seem to
> work for 'session' parameters. Is there any way to access session
> parameters in a const context?
>
The session data doesn't have pick(), but should be accessible in a const
context. Are you able to post a short test case please?
I've wondered about this inconsistency before, but decided against "fleshing
out" the session to have the same members as the other request data. The
basic_session<> class template is as slim as possible since the idea is that
library users can customise it. The class itself is little more than:
template<typename T>
class basic_session : public T, noncopyable
{
// getter / setter for the session id.
string const& id() const;
void id(string const&);
// check / set if the session is loaded.
bool loaded() const;
void loaded(bool);
};
The only reason count(), et al. exist is that T defaults to
std::map<string,string>. One option that is possible is to default T to a
wrapper over std::map<> that adds the pick(), etc. members.
Thoughts?
Cheers,
Darren
|
|
From: Darren G. <lis...@go...> - 2010-07-26 23:43:38
|
Hi Ankur, On 26 July 2010 07:02, Ankur Gupta <ank...@gm...> wrote: > Is there any timeline for Unix domain sockets implementation? This should > help performance quite a bit I feel. > I have been making a large chunk of changes locally, none of which are in the repository quite yet. These changes include support for TCP sockets on Windows (ie. for external FastCGI) and for Unix sockets, both of which are compile-time choices. There is also an experimental dynamic wrapper over the main classes of the library, which allows for protocol and / or connection type to be picked at runtime. I will try and find time to commit these in the next couple of weeks. Especially with the dynamic CGI stuff, I'm still a bit unsure about the naming conventions, async functionality and a couple of other details so it'd be interesting to see what other's thoughts were. Cheers, Darren |
|
From: Ankur G. <ank...@gm...> - 2010-07-26 06:02:48
|
Hi Darren, Is there any timeline for Unix domain sockets implementation? This should help performance quite a bit I feel. Thanks, Ankur |
|
From: Richard F. <ri...@th...> - 2010-07-06 11:41:28
|
Hi Darren, Thanks for responding so quickly to my bug report yesterday. Today I have a const correctness problem. I have a 'request' object that has been passed by const reference and would like to query the contents of its get, session etc. 1. data_map_proxy::count(const key_type&) is not a const member function. Is there any reason for that? I tried changing it to const without any obvious problems. 2. I can use pick() to access 'get' parameters but it does not seem to work for 'session' parameters. Is there any way to access session parameters in a const context? Best regards, Richard |
|
From: Scott B. <Ba...@In...> - 2010-06-17 16:40:50
|
JCR, You should care about maintainability. Hard coding the source location makes it harder to maintain. It is better to add the following to your compile command (g++, I presume): -I /websites/libraries/boost/cgi-0.7.1/ Furthermore, it's easier to share your code with others who will put their libraries elsewhere. On Thu, Jun 17, 2010 at 8:49 AM, Darren Garvey <dar...@gm...>wrote: > On 17 June 2010 15:07, <jc...@ol...> wrote: > >> >> >> My boost installation is at /usr/local/include/ and I downloaded cgi >> >> C++ >> >> >> at /websites/libraries. Is there a difference between: >> >> >> #include <boost/cgi/fcgi.hpp> >> >> >> #include "/websites/libraries/boost/cgi-0.7.1/boost/cgi/fcgi.hpp" >> >> >> >> > you should prefer the first option. Configure your PATH or >> >> > compiler to search for the correct version of the CGI library and use >> >> > <boost/cgi/fcgi.hpp> >> >> >> >> (1) What do I risk if I go with the first second option? >> >> >> > >> > Could you clarify? ;) >> >> My question definitely requires clarification! :) >> >> If I go with the first option and write: >> #include "/websites/libraries/boost/cgi-0.7.1/boost/cgi/fcgi.hpp" >> what do I risk? >> Why is >> #include <boost/cgi/fcgi.hpp> >> better? > > > The full path ties your source down to one path for the library. If you > #include <boost/cgi/fcgi.hpp>, then add a new version of the CGI lib to, say > "/websites/libraries/boost/cgi-0.8/boost/cgi/fcgi.hpp" then all you need to > do is change your PATH and recompile. If you specify full paths you need to > change source files. Ick! > > -- Scott Bailey |
|
From: Darren G. <dar...@gm...> - 2010-06-17 15:50:04
|
On 17 June 2010 15:07, <jc...@ol...> wrote: > >> >> My boost installation is at /usr/local/include/ and I downloaded cgi > >> C++ > >> >> at /websites/libraries. Is there a difference between: > >> >> #include <boost/cgi/fcgi.hpp> > >> >> #include "/websites/libraries/boost/cgi-0.7.1/boost/cgi/fcgi.hpp" > >> > >> > you should prefer the first option. Configure your PATH or > >> > compiler to search for the correct version of the CGI library and use > >> > <boost/cgi/fcgi.hpp> > >> > >> (1) What do I risk if I go with the first second option? > >> > > > > Could you clarify? ;) > > My question definitely requires clarification! :) > > If I go with the first option and write: > #include "/websites/libraries/boost/cgi-0.7.1/boost/cgi/fcgi.hpp" > what do I risk? > Why is > #include <boost/cgi/fcgi.hpp> > better? The full path ties your source down to one path for the library. If you #include <boost/cgi/fcgi.hpp>, then add a new version of the CGI lib to, say "/websites/libraries/boost/cgi-0.8/boost/cgi/fcgi.hpp" then all you need to do is change your PATH and recompile. If you specify full paths you need to change source files. Ick! > I'll add something to the docs around this - the idea is getting started > > takes 5 minutes (+ compile times for Boost) so comments here are very > > useful. > > I compiled boost 1.43 with ./bootstrap.sh ./bjam and ./bjam install and > the headers take 67MB while the libraries take 27MB. That's not much > space! And it did not take that long on my Centos 5 box. I am not sure I > will ever need wave but not excluding it makes the whole process so much > easier. > This is with the new default options, which only builds release mode and certain variants. If you try "bjam --build-type=complete install" then you'll have well over 2 Gigs of libraries! > With nginx I lost a lot of time trying to connect nginx with my app. > supervisord was the key to make the whole process easier. > > One benefit of supervisord is that it manages the replacement of an old > app with a newer version. I remember that with Apache, I had to kill the > instances myself... I actually started thinking that the fast CGI library > should check for a newer version of the app and exit... This step of > replacing an app is obviously quite important for web development. > This is an interesting problem. It'd be great to have some documentation around this. Feel free to submit a patch if I don't get to do this! Cheers, Darren |
|
From: <jc...@ol...> - 2010-06-17 14:08:00
|
>> >> My boost installation is at /usr/local/include/ and I downloaded cgi >> C++ >> >> at /websites/libraries. Is there a difference between: >> >> #include <boost/cgi/fcgi.hpp> >> >> #include "/websites/libraries/boost/cgi-0.7.1/boost/cgi/fcgi.hpp" >> >> > you should prefer the first option. Configure your PATH or >> > compiler to search for the correct version of the CGI library and use >> > <boost/cgi/fcgi.hpp> >> >> (1) What do I risk if I go with the first second option? >> > > Could you clarify? ;) My question definitely requires clarification! :) If I go with the first option and write: #include "/websites/libraries/boost/cgi-0.7.1/boost/cgi/fcgi.hpp" what do I risk? Why is #include <boost/cgi/fcgi.hpp> better? > I'll add something to the docs around this - the idea is getting started > takes 5 minutes (+ compile times for Boost) so comments here are very > useful. I compiled boost 1.43 with ./bootstrap.sh ./bjam and ./bjam install and the headers take 67MB while the libraries take 27MB. That's not much space! And it did not take that long on my Centos 5 box. I am not sure I will ever need wave but not excluding it makes the whole process so much easier. With nginx I lost a lot of time trying to connect nginx with my app. supervisord was the key to make the whole process easier. One benefit of supervisord is that it manages the replacement of an old app with a newer version. I remember that with Apache, I had to kill the instances myself... I actually started thinking that the fast CGI library should check for a newer version of the app and exit... This step of replacing an app is obviously quite important for web development. JCR > On 17 June 2010 14:18, <jc...@ol...> wrote: > >> Darren, >> >> Thanks for all the answers. >> >> >> My boost installation is at /usr/local/include/ and I downloaded cgi >> C++ >> >> at /websites/libraries. Is there a difference between: >> >> #include <boost/cgi/fcgi.hpp> >> >> #include "/websites/libraries/boost/cgi-0.7.1/boost/cgi/fcgi.hpp" >> >> > you should prefer the first option. Configure your PATH or >> > compiler to search for the correct version of the CGI library and use >> > <boost/cgi/fcgi.hpp> >> >> (1) What do I risk if I go with the first second option? >> > > Could you clarify? ;) > > >> (2) The "installation" section of the doc would benefit from adding a >> few >> lines at the beginning explaining that once the standard boost is >> compiled >> and installed (by default in /usr/local for many linux distro I guess), >> then it is only a question of dropping off cgi into >> /usr/local/include/boost. As it is now it is unnecessary daunting. >> > > You should generally only have to add "/path/to/cgi_root" to your system > PATH. Adding the includes to /usr/include/boost is not required. I'll add > something to the docs around this - the idea is getting started takes 5 > minutes (+ compile times for Boost) so comments here are very useful. > > (3) Does the library require the fastcgi toolkit available at fastcgi.com. >> Does it contain its own implementation of the FastCGI protocol? >> > > You don't need the FastCGI toolkit - the library fully implements FastCGI > using Boost.Asio. > > Cheers, > Darren > |
|
From: Darren G. <lis...@gm...> - 2010-06-17 13:43:57
|
On 17 June 2010 14:18, <jc...@ol...> wrote: > Darren, > > Thanks for all the answers. > > >> My boost installation is at /usr/local/include/ and I downloaded cgi C++ > >> at /websites/libraries. Is there a difference between: > >> #include <boost/cgi/fcgi.hpp> > >> #include "/websites/libraries/boost/cgi-0.7.1/boost/cgi/fcgi.hpp" > > > you should prefer the first option. Configure your PATH or > > compiler to search for the correct version of the CGI library and use > > <boost/cgi/fcgi.hpp> > > (1) What do I risk if I go with the first second option? > Could you clarify? ;) > (2) The "installation" section of the doc would benefit from adding a few > lines at the beginning explaining that once the standard boost is compiled > and installed (by default in /usr/local for many linux distro I guess), > then it is only a question of dropping off cgi into > /usr/local/include/boost. As it is now it is unnecessary daunting. > You should generally only have to add "/path/to/cgi_root" to your system PATH. Adding the includes to /usr/include/boost is not required. I'll add something to the docs around this - the idea is getting started takes 5 minutes (+ compile times for Boost) so comments here are very useful. (3) Does the library require the fastcgi toolkit available at fastcgi.com. > Does it contain its own implementation of the FastCGI protocol? > You don't need the FastCGI toolkit - the library fully implements FastCGI using Boost.Asio. Cheers, Darren |
|
From: <jc...@ol...> - 2010-06-17 13:18:41
|
Darren, Thanks for all the answers. >> My boost installation is at /usr/local/include/ and I downloaded cgi C++ >> at /websites/libraries. Is there a difference between: >> #include <boost/cgi/fcgi.hpp> >> #include "/websites/libraries/boost/cgi-0.7.1/boost/cgi/fcgi.hpp" > you should prefer the first option. Configure your PATH or > compiler to search for the correct version of the CGI library and use > <boost/cgi/fcgi.hpp> (1) What do I risk if I go with the first second option? (2) The "installation" section of the doc would benefit from adding a few lines at the beginning explaining that once the standard boost is compiled and installed (by default in /usr/local for many linux distro I guess), then it is only a question of dropping off cgi into /usr/local/include/boost. As it is now it is unnecessary daunting. (3) Does the library require the fastcgi toolkit available at fastcgi.com. Does it contain its own implementation of the FastCGI protocol? JCR > Hi, > > On 16 June 2010 17:42, <jc...@ol...> wrote: > >> Hello Darren, >> >> I really like your library and it has improved significantly from a year >> ago. Congratulations. This is really great to have such a tool. Even for >> simple apps, using C++ makes sense as you never know how the app will >> need >> to scale and it is always good to practice a skill for the day it will >> be >> really required. C++ web development involves a more sophisticated setup >> than let's say php but once it is done it is not really more difficult >> and >> it is so much more comfortable. In terms of design, I like that >> extensions >> like database access are not in the library but are demonstrated with >> examples. >> > > I agree. Thanks! > > >> A few (dummy) questions: >> >> (1) >> My boost installation is at /usr/local/include/ and I downloaded cgi C++ >> at >> /websites/libraries. Is there a difference between: >> >> #include <boost/cgi/fcgi.hpp> >> and >> #"/websites/libraries/boost/cgi-0.7.1/boost/cgi/fcgi.hpp" >> > > Do you mean: > > #include "/websites/libraries/boost/cgi-0.7.1/boost/cgi/fcgi.hpp" > > ? > > If so, then you should prefer the first option. Configure your PATH or > compiler to search for the correct version of the CGI library and use > <boost/cgi/fcgi.hpp> > > (2) >> When you write >> resp<< content_type("text/plain") >> << header("X-Protocol", "FastCGI") >> << "Hello there, universe."; >> is it the same as >> resp << >> with a space >> > > No difference. "resp<<" is calling "basic_response<>::operator<<". > Whitespace is generally not significant in C++. > > >> (3) >> Example / async_echo >> >> I am trying to compile and I am getting the errors: >> main.cpp: In function int handle_request(boost::cgi::fcgi::acceptor&, >> boost::cgi::fcgi::request&): >> main.cpp:116: error: struct >> boost::cgi::common::basic_request<boost::cgi::common::tags::fcgi> has >> no >> member named hash >> main.cpp: In function int main(): >> main.cpp:173: error: no matching function for call to >> >> boost::cgi::common::basic_request_acceptor<boost::cgi::common::tags::fcgi>::basic_request_acceptor() >> /usr/local/include/boost/cgi/basic_request_acceptor.hpp:33: note: >> candidates are: >> >> boost::cgi::common::basic_request_acceptor<boost::cgi::common::tags::fcgi>::basic_request_acceptor(const >> >> boost::cgi::common::basic_request_acceptor<boost::cgi::common::tags::fcgi>&) >> > > Thanks for the report. I removed the support for Boost.Hash as it didn't > seem necessary, so request.hash() is no longer valid. Also, the acceptor > constructor needs to take an fcgi::service and can be used the same on > both > Windows and Linux. Again, I've attached a patch for this example. > > Also, I am wondering what the use case of async_load or async_accept, >> > > These functions are to allow for efficient accepting and loading of > requests. As an example, if someone wanted to write a high-level web > development framework, then I imagine that this would include a > "dispatcher" > or "server" that was responsible for accepting and loading requests before > handing them off to application code. > > The accepting and loading stages involve accepting connections then > reading > and parsing data, which are generally blocking operations. Using the > async_* > functions would allow for much more scalable code because OS-specific > non-blocking APIs could be used under the hood. > > I'm not happy with the async FastCGI parts at the moment and have been > rewriting the FastCGI functionality locally to make them work better. I > hope > to get this finished soon. > > Cheers, > Darren > |
|
From: Darren G. <lis...@go...> - 2010-06-17 08:54:07
|
On 17 June 2010 02:30, <jc...@ol...> wrote: > Hello, > > I often need to do additional stuff once the response to send back to the > client is ready. Instead of waiting for the additional stuff to be done, I > thought that I could just commit and then do my additional stuff. > I am wondering if the request data are still available and if this is a > good design. > Yes this is a perfectly valid use-case. The request is explicitly closed by commit() and this means you can't read / write any more data but all of the request information is still available until you either: a) call request::clear() b) accept a new request on a closed request (which internally calls request::clear()) I've added documenting this to my TODO. Cheers, Darren |
|
From: Darren G. <lis...@gm...> - 2010-06-17 08:47:00
|
On 16 June 2010 14:22, <jc...@ol...> wrote:
>
> Below, I am describing my setup for nginx and FastCGI / CGI C++ Librarym
> in case someone is interested.
>
> Step 1
> nginx.conf
> http {
> ...
> server {
> ...
> location ~ \.toff$ {
> include /usr/local/nginx/conf/fastcgi.conf;
> fastcgi_pass 127.0.0.1:9000;
> }
> }
> location is written that way because it so happens that all my fasctgi app
> have an .toff extension
>
> Step 2
> Since nginx does not serve cgi scripts, it is up to the developer to find
> a way to have nginx and the CGI app. I am using supervisord, which is "a
> client/server system that allows its users to control a number of
> processes on UNIX-like operating systems" (see supervisord.org).
>
> /etc/supervisord.conf
> ...
> 131 [fcgi-program:chat]
> 132 command=/path/chat.toff
> 133 socket=tcp://127.0.0.1:9000
> 134 process_name=%(program_name)s_%(process_num)02d
> 135 numprocs=1
> 136 priority=999
> 137 autostart=true
> 138 autorestart=unexpected
> 139 startsecs=1
> 140 startretries=3
> 141 exitcodes=0,2
> 142 stopsignal=QUIT
> 143 stopwaitsecs=10
>
> Step 3
> to compile a FastCGI / CGI C++ Library, I do the following:
> g++ -Wall ...
> supervisorctl restart chat:*
>
Would you mind if I used this in the setup section of the docs?
Cheers,
Darren
|
|
From: <jc...@ol...> - 2010-06-17 02:00:33
|
Hello,
I often need to do additional stuff once the response to send back to the
client is ready. Instead of waiting for the additional stuff to be done, I
thought that I could just commit and then do my additional stuff.
I am wondering if the request data are still available and if this is a
good design. On one hand the below codes seem to work for me but from the
file common/commit.hpp, I understand that commit "Send a response to a
reqest and close off the request." So I am wondering if below is the
proper way to do what I would like to do. I am using fastcgi.
Thank you very much for your answers
JCR
template<typename Request, typename Response>
int handle_request(Request& req, Response& resp)
{
req.load(parse_all);
resp<< content_type("text/plain")
<< header("X-Protocol", "FastCGI")
<< "Hello there, universe."
<< req.id();
commit(req, resp, 0);
//do additional stuff
sleep(10);
write_to_file("aa",req.env["HTTP_HOST"]);
return 1;
}
|
|
From: <jc...@ol...> - 2010-06-16 16:42:49
|
Hello Darren,
I really like your library and it has improved significantly from a year
ago. Congratulations. This is really great to have such a tool. Even for
simple apps, using C++ makes sense as you never know how the app will need
to scale and it is always good to practice a skill for the day it will be
really required. C++ web development involves a more sophisticated setup
than let's say php but once it is done it is not really more difficult and
it is so much more comfortable. In terms of design, I like that extensions
like database access are not in the library but are demonstrated with
examples.
A few (dummy) questions:
(1)
My boost installation is at /usr/local/include/ and I downloaded cgi C++ at
/websites/libraries. Is there a difference between:
#include <boost/cgi/fcgi.hpp>
and
#"/websites/libraries/boost/cgi-0.7.1/boost/cgi/fcgi.hpp"
(2)
When you write
resp<< content_type("text/plain")
<< header("X-Protocol", "FastCGI")
<< "Hello there, universe.";
is it the same as
resp <<
with a space
(3)
Example / async_echo
I am trying to compile and I am getting the errors:
main.cpp: In function int handle_request(boost::cgi::fcgi::acceptor&,
boost::cgi::fcgi::request&):
main.cpp:116: error: struct
boost::cgi::common::basic_request<boost::cgi::common::tags::fcgi> has no
member named hash
main.cpp: In function int main():
main.cpp:173: error: no matching function for call to
boost::cgi::common::basic_request_acceptor<boost::cgi::common::tags::fcgi>::basic_request_acceptor()
/usr/local/include/boost/cgi/basic_request_acceptor.hpp:33: note:
candidates are:
boost::cgi::common::basic_request_acceptor<boost::cgi::common::tags::fcgi>::basic_request_acceptor(const
boost::cgi::common::basic_request_acceptor<boost::cgi::common::tags::fcgi>&)
Also, I am wondering what the use case of async_load or async_accept,
thanks
Jean-Christophe Roux
|
|
From: <jc...@ol...> - 2010-06-16 13:22:19
|
Hello Darren,
> I think this might be due to nginx sending through empty parameters at the
> end of a FCGI_PARAMS packet.
Thanks for the patch. I applied it and the problem is gone. Excellent!
Below, I am describing my setup for nginx and FastCGI / CGI C++ Librarym
in case someone is interested.
Step 1
nginx.conf
http {
...
server {
...
location ~ \.toff$ {
include /usr/local/nginx/conf/fastcgi.conf;
fastcgi_pass 127.0.0.1:9000;
}
}
location is written that way because it so happens that all my fasctgi app
have an .toff extension
Step 2
Since nginx does not serve cgi scripts, it is up to the developer to find
a way to have nginx and the CGI app. I am using supervisord, which is "a
client/server system that allows its users to control a number of
processes on UNIX-like operating systems" (see supervisord.org).
/etc/supervisord.conf
...
131 [fcgi-program:chat]
132 command=/path/chat.toff
133 socket=tcp://127.0.0.1:9000
134 process_name=%(program_name)s_%(process_num)02d
135 numprocs=1
136 priority=999
137 autostart=true
138 autorestart=unexpected
139 startsecs=1
140 startretries=3
141 exitcodes=0,2
142 stopsignal=QUIT
143 stopwaitsecs=10
Step 3
to compile a FastCGI / CGI C++ Library, I do the following:
g++ -Wall ...
supervisorctl restart chat:*
JCR
> Hi there,
>
> On 15 June 2010 22:53, <jc...@ol...> wrote:
>
>> Hello,
>>
>> I am using the cgi-0.7.1 on a Centos box with nginx as webserver. I am
>> also using supervisord to keep my app chat.toff up.
>> chat.toff contains the code of the Fastcgi examples - Echo.
>>
>
> Interesting - that's not a platform I've tried the library with before.
>
>
>> If I type example.com/chat.toff?
>> it works fine
>> but if I type example.com/chat.toff
>> it fails with the following information in the log of nginx:
>>
>> 2010/06/15 17:41:07 [error] 31508#0: *688 recv() failed (104: Connection
>> reset by peer) while reading response header from upstream, client:
>> 70.48.64.188, server: *.example.com, request: "GET /chat.toff HTTP/1.1",
>> upstream: "fastcgi://127.0.0.1:9000", host: "www.example.com:8080"
>>
>> Any idea What the problem is?
>>
>
> I think this might be due to nginx sending through empty parameters at the
> end of a FCGI_PARAMS packet.
>
> Can you try the attached patch to see if it helps?
>
> In any case, I am quite excited to have a CGI library around boost...
>>
>> Thank you
>>
>
> Good to hear it! Thanks for the feedback.
>
> Cheers,
> Darren
>
|
|
From: <jc...@ol...> - 2010-06-15 21:54:05
|
Hello, I am using the cgi-0.7.1 on a Centos box with nginx as webserver. I am also using supervisord to keep my app chat.toff up. chat.toff contains the code of the Fastcgi examples - Echo. If I type example.com/chat.toff? it works fine but if I type example.com/chat.toff it fails with the following information in the log of nginx: 2010/06/15 17:41:07 [error] 31508#0: *688 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 70.48.64.188, server: *.example.com, request: "GET /chat.toff HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.example.com:8080" Any idea What the problem is? In any case, I am quite excited to have a CGI library around boost... Thank you |
|
From: Darren G. <dar...@gm...> - 2010-05-18 00:38:31
|
Hi, Just a note to you all, I have removed the 301 redirect from the sourceforge site and put the documentation files up at http://cgi.sf.net/docs. Apologies for the change of domain, but as I have now figured out how to (mostly) automate updating the sourceforge site this isn't so much of a burden as it used to be. I will probably remove the CGI / FastCGI related pages from omnisplat.com in the next few days so update any links you have. As an aside, I added a sample apache configuration snippet for getting CGI and FastCGI working to the documentation: http://cgi.sourceforge.net/docs/fastcgi___cgi/tutorial/server_configuration.html Cheers, Darren |
|
From: Darren G. <dar...@gm...> - 2010-05-16 10:58:46
|
All, I have just posted a new release of the CGI / FastCGI library to Sourceforge, available from: https://sourceforge.net/projects/cgi/files The tar.bz2 file uses unix line endings while the .7z and .zip files use Windows line endings. This point release fixes a bug in the 0.7 release which caused compile errors under linux. I'm afraid for those that wish to compile with -Wall -Werror may have problems as the Boost libraries used do not all compile cleanly with -Wall -Werror... yet. The documentation is under construction, but has been uploaded in its partial state to: http://cgi.sf.net/docs Hopefully I can find time to continue cleaning the API and finish off the documentation. As always, comments and critique are most welcome. Happy hacking! Cheers, Darren |
|
From: Darren G. <dar...@gm...> - 2010-03-24 17:24:35
|
On 24 March 2010 16:20, Scott Bailey <Ba...@in...> wrote: > Darren, > > a quick update and compile shows a collision of role_type: > boost/cgi/common/protocol_traits.hpp:101: error: *declaration of 'typedef > enum boost::cgi::common::role_type * > boost::cgi::common::protocol_traits<boost::cgi::common::tags::cgi>::role_type' > boost/cgi/common/role_type.hpp:24: error: *changes meaning of 'role_type' > from 'enum boost::cgi::common::role_type'* > > But, honestly, I don't see why... > It looks like gcc scoping rules at a first glance. I'll take a look when I get home. > I've simply turned off warnings for the time being. I really am just > tinkering as time allows. When I was checking into the unused parameters, I > was suspicious that some of those unused parameters should be used... > That's where I decided I was in over my head, at least with the time > allotted at present. > > Regardless, I'm glad to see you are still working it. > Hmm, yes. Documentation still pending I'm afraid... Thanks for the report! Cheers, Darren |
|
From: Scott B. <Ba...@In...> - 2010-03-24 16:20:37
|
Darren, a quick update and compile shows a collision of role_type: boost/cgi/common/protocol_traits.hpp:101: error: *declaration of 'typedef enum boost::cgi::common::role_type * boost::cgi::common::protocol_traits<boost::cgi::common::tags::cgi>::role_type' boost/cgi/common/role_type.hpp:24: error: *changes meaning of 'role_type' from 'enum boost::cgi::common::role_type'* But, honestly, I don't see why... I've simply turned off warnings for the time being. I really am just tinkering as time allows. When I was checking into the unused parameters, I was suspicious that some of those unused parameters should be used... That's where I decided I was in over my head, at least with the time allotted at present. Regardless, I'm glad to see you are still working it. SB On Tue, Mar 23, 2010 at 6:02 PM, Darren Garvey <dar...@gm...>wrote: > Hi Scott, > > Apologies for the delay, I took some time off. :) > > On 2 March 2010 19:58, Scott Bailey <Ba...@in...> wrote: > > Regarding the unused variables, please look! I'm in over my head anytime I >> look at ASIO, and the first warning I wen to look at was an unused variable >> with a default value that was somehow related to ASIO! I'm not ready to >> tackle that, yet! >> > > I've taken a look at the unused variables and will get around to removing > them when I can find the time - rather than just remove them I'd prefer to > obliterate the bits of code that are lying around with unused parameters. > Feel free to ping me on this one! > > I'm just about to commit a few changes and cleanups related mostly to > sessions (which should be in working order now). I'll check this with gcc > tomorrow at some point just in case there are issues, unless you get there > first. > > Cheers, > Darren > -- Scott Bailey |
|
From: Darren G. <dar...@gm...> - 2010-03-24 01:03:12
|
Hi Scott, Apologies for the delay, I took some time off. :) On 2 March 2010 19:58, Scott Bailey <Ba...@in...> wrote: Regarding the unused variables, please look! I'm in over my head anytime I > look at ASIO, and the first warning I wen to look at was an unused variable > with a default value that was somehow related to ASIO! I'm not ready to > tackle that, yet! > I've taken a look at the unused variables and will get around to removing them when I can find the time - rather than just remove them I'd prefer to obliterate the bits of code that are lying around with unused parameters. Feel free to ping me on this one! I'm just about to commit a few changes and cleanups related mostly to sessions (which should be in working order now). I'll check this with gcc tomorrow at some point just in case there are issues, unless you get there first. Cheers, Darren |
|
From: Scott B. <Ba...@In...> - 2010-03-02 20:21:11
|
Darren, Glad the changes looked OK. Here's my version info: b2$ g++ --version g++ (Debian 4.3.2-1.1) 4.3.2 Why does my installation have a problem, but not yours...? I don't know. Regarding the unused variables, please look! I'm in over my head anytime I look at ASIO, and the first warning I wen to look at was an unused variable with a default value that was somehow related to ASIO! I'm not ready to tackle that, yet! However, I did get the hello world and echo programs working and modified a little bit. Lots of fun! Thank you very much! SB On Tue, Mar 2, 2010 at 12:32 PM, Darren Garvey <dar...@gm...>wrote: > > Yeah, the changes are small. The -Wall changes are more significant. Lots >> of unused variables. I won't get to this for awhile... >> > > What version of g++ are you using? I'm suprised these weren't flagged up by > g++ 4.3.2 or MSVC 9.0. Your patch looks ok though and I committed it to > trunk last night. > > I'll think I might take a look at the "-Wall -Werror" problems. I suspect > there may be a few more unused variables that need cleaning. > > Cheers, > Darren > > -- Scott Bailey |
|
From: Darren G. <dar...@gm...> - 2010-03-02 19:32:44
|
Hi Scott, On 1 March 2010 19:55, Scott Bailey <Ba...@in...> wrote: > Darren, > > I'm going to post to the list & CC you. Traffic on the list shows a living > project. > Indeed, thanks. Yeah, the changes are small. The -Wall changes are more significant. Lots > of unused variables. I won't get to this for awhile... > What version of g++ are you using? I'm suprised these weren't flagged up by g++ 4.3.2 or MSVC 9.0. Your patch looks ok though and I committed it to trunk last night. I'll think I might take a look at the "-Wall -Werror" problems. I suspect there may be a few more unused variables that need cleaning. Cheers, Darren |
|
From: Scott B. <Ba...@In...> - 2010-03-01 19:55:44
|
Darren, I'm going to post to the list & CC you. Traffic on the list shows a living project. Yeah, the changes are small. The -Wall changes are more significant. Lots of unused variables. I won't get to this for awhile... SB On Mon, Mar 1, 2010 at 12:42 PM, Darren Garvey <dar...@gm...>wrote: > Hi Scott, > > On 1 March 2010 17:47, Scott Bailey <Ba...@in...> wrote: > >> Darren, >> >> Thanks, that works in Linux with a couple minor changes. I'll get you a >> patch soon. I'll follow it up with the -Wall changes, too. >> > > Grr, I hope the changes really were minor! Patches are most welcome - > posting it to the list / me is fine. > > Cheers, > Darren > -- Scott Bailey |
|
From: Darren G. <dar...@gm...> - 2010-03-01 19:43:28
|
Hi Scott, On 1 March 2010 17:47, Scott Bailey <Ba...@in...> wrote: > Darren, > > Thanks, that works in Linux with a couple minor changes. I'll get you a > patch soon. I'll follow it up with the -Wall changes, too. > Grr, I hope the changes really were minor! Patches are most welcome - posting it to the list / me is fine. Cheers, Darren |
|
From: Scott B. <Ba...@In...> - 2010-03-01 17:47:18
|
Darren, Thanks, that works in Linux with a couple minor changes. I'll get you a patch soon. I'll follow it up with the -Wall changes, too. SB On Sun, Feb 28, 2010 at 10:08 AM, Darren Garvey <dar...@gm...>wrote: > Hi Scott, > > On 27 February 2010 18:21, Scott Bailey <Ba...@in...> wrote: > >> Darren, >> >> Have you compiled the 'fcgi/hello_world/' program recently? In Linux w/ >> boost 1.42.0 I'm running into quite a few compile issues. I'm thinking some >> of these won't compile in Windows... >> > > Looks like the last commit broke a few things with FastCGI... I have just > committed some fixes which should have fixed this for now. > > Let me know how you get on. > > Cheers, > Darren > -- Scott Bailey |
2 messages has been excluded from this view by a project administrator.
