Hi,
thank you for your feedback. I would like to comment it a bit.
You want to serve static pages from file system from tntnet. Since this is a
very common task you suggest, that tntnet should have it built in. Luckily
tntnet has such a feature. Not directly built in but as a component, which it
delivered with tntnet. The component name is sta...@tntnet. So all you have to
do is to map the url scheme, you want to that component and pass the desired
file name as a parameter in your tntnet.conf
There is indeed a feature, you can use to pass filenames from tntnet.conf to
the component. By default request.getPathInfo() returns the url part from the
request, but you can override it in tntnet.conf. And this can be done for
sta...@tntnet.
So here it is how to do it. We want to serve files from /var/www:
MapUrl ^(.*)/$ sta...@tntnet /var/www/$1/index.html
MapUrl ^/(.*)$ sta...@tntnet /var/www/$1
The first mapping maps every url ending with a slash to a index.html. The
second maps the rest.
sta...@tntnet does even a little bit more. It looks at the extension and sets
the content type properly for that. Known file extensions are read from
/etc/mime.types. But you can also override the content type if you want by
passing another parameter to the component. E.g.:
MapUrl ^/images/(.*) sta...@tntnet /var/www/imges/$1 image/jpeg
sends all files in the specified directory with the content type image/jpeg.
And another feature: if the file is not found, sta...@tntnet do not send a 404
but returns DECLINED (which you can do also in your component), so tntnet
looks for the next mapping. If you have e.g. a css file built in to your
application and temporarily want to override it, you can do that easily:
MapUrl ^/myapp.css$ sta...@tntnet /home/foo/bar/myapp.css
MapUrl ^/(.*)\.css$ $1_...@myapp
If you have a myapp_css in your application it can be reached with the url
/myapp.css. But only if the file /home/foo/bar/myapp.css does not exist.
One good thing about that is also, that you do not need to rely on the current
working directory, since you use full paths. Tntnet itself do not change the
current working directory when not configured to do so (with the Dir setting in
tntnet.conf), so you may even use relative paths when developing.
I should add that the famous double dot attack is already addressed in tntnet.
Someone may try use http://myhost:8000/../../etc/passwd to read the password
file. This is already catched by tntnet before it starts looking for mappings.
Also I can give you some tips regarding your implementation:
You should really use <%cpp></%cpp> instead of <{...}>. The former discards a
trailing line feed, the latter not. This may be important for some file types.
Instead of sending each character separately you may want to use the output
operator for std::streambuf*. This is a rather strange and unknown feature of
iostream but very useful:
reply.out() << f.rdbuf();
Copies the file to the output in one call.
And the flag std::ios::binary has no effect in most operating systems. The only
OS I know, which makes a distinction is windows.
Tommi
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Tntnet-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tntnet-general
