Re: [Cppcms-users] Some remarks

[Artyom <art...@ya...>]

Hello

> Can someone explain me how to use cppcms_run for a production release or is it 
> not suitable for that?

Defenatly not. cppcms_run is just tool for debugging and testing the framework
agains different web servers.

You should run CppCMS process just like and other FastCGI process and you should 
refer to the web server documentation.

In general there are two ways of running
1. Run web server and start cppcms service externally -- that what cppcms run does.
2. Make web server manage CppCMS applications (Not supported by Nginx)

For example. This is configuration of production CppCMS wiki service for lighttpd:

server.modules   += ( "mod_fastcgi" )

fastcgi.server    = ( 
        "/wikipp" =>
        ((
                "bin-path" => "/some/path/to/wikipp -c /some/path/to/config-wikipp.txt",
                "socket" => "/tmp/wikipp.socket",
                "max-procs" => 1,
                "check-local" => "disable"
        ))
)

Notes:

a) max-procs == 1 -- make sure that only one process is started. CppCMS controls its processes
on its own.
b) check-local = disable -- do to try to find a real executable or script.
c) Also config-wikipp.txt DOES NOT define specific socket in order to use stdin as socket.
See: http://art-blog.no-ip.info/wikipp/en/page/ref_config#server-api
d) When web server starts application it runs under web server permissions, if you want to limit it even more
   you may use various mods like chroot etc.

Generally just run cppcms_run and take a look on created configuration and start working with them.
CppCMS is just a simple FastCGI or SCGI service.


-------------------

> I am a bit confused why the document root is an absolut path, while the fcgi 
> process must be relative:
> /usr/local/bin/cppcms_run: line 474: ./MY_ABS_PATH/hello.fcgi: File not found
> (so ./ is prefixed there)

It is just because I'm too lazy to write full path. So cppcms_run assumes that the script is placed in current
working directory and it names script -- the base path according to program name by default.

cppcms_run mostly used for testing and debugging.

>  2.) How can I run the site at the root of the server?
> 
> When I use -s /hello, I can access the site at http://markusbyte:8080/hello/.
> How can I completely avoid the /hello/ to access the site at 
> http://markusbyte:8080/.
> 
> I hope it can be done without rewrite rules. It would be perfect if there is a 
> webserver independend way?


Generally it is **bad** idea. And I explain why. Web server does much more
then providing fast-cgi service it also serves files. If hello is related to / then
if you want to get a file "/hello.css" you need to know how to serve it VIA your program, and beleve me YOU DO NOT
want to do this because serving files has LOTs of security issues that should be handled 
correctly.

Generally you may specify as script "/", but some web servers have problem with that.

> 3.) Using filters in other classes than base_view.
> 
> The filters like escape can be only used in base_view classes (or classes 
> inheriting from it) and I don't see any reason why. In addition to that there 
> are not const, but they don't modify the object (they just return a string).
> 

They are not const but some filter may be non-const. Just think that you may to access
DB from filter if cache is not avalible (not that it is correct way to do this)

> I would suggest to make them as functions or static methods.
> ---------

In CppCMS 1.x.x they are static methods.

There is one more important quite technical point why these functions are members.

Lest assume you have some filter

class foo : public cppcms::base_view{
    string bar_filter(string somethings);
};

When you compile the template to shared object it does not know what foo::foo_bar filter is and it is 
resolved only when it is "dlopened" This is defenatly not a problem for ELF platform but it is a huge
problem for DLL platform. DLLs may have no unresolved symbols!

So this problem is simply workarounded by making bar_filter virtual, thus DLL should only know the class
layout and not need to know the resolution of specific symbols. So if you want to create custom filter you need to
provide them somehow via callback methods -- this means they should be somehow members of your views known in compilation time.

boost::function can be used as well (when it is member of class).

> 4.) Wrong mime type for failure pages.
> 
> For 500 internal server errors, 404 document not found and so on the 
> Content-Type is text/plain even though a html page is shown[0].

Ok I need to check this. When do you get page of size "0" generally when 
500 or 404 error occures an html page is generated as well? How do you 
get such error?


> 5.) Interface to set_header.
> 
> In cppcms::application set_header takes a pointer to HTTPHeader. When I look 
> into cppcms::worker_thread::set_header I see that a auto_ptr is taking 
> ownership of this pointer. Maybe the documentation points out that too, but 
> it would be much clearer if the the auto_ptr is used in the interface. Having 
> that, it would be easy to see that you can pass a fresh allocated object 
> without having to worry what will happen. So it should read:
> 
> void set_header(std::auto_ptr<cgicc::HTTPHeader> h) { worker.set_header(h); }
> 

I am absolutly agree, but I must admit that all http headers stuff is quite conceptually broken because 
of very bad design of CgiCC library CppCMS uses. It is totally rewritten in CppCMS 1.x.x


HTTP/1.1 404 Not found
Date: Tue, 27 Oct 2009 13:46:24 GMT
Server: Apache/2.2.9 (Debian) mod_fastcgi/2.4.6
X-Powered-By: cppcms/0.0.4
Content-Length: 248
Connection: close
Content-Type: text/plain

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"


Ok I'll check this.

Best,
  Artyom