ios::binary DOES have an effect - I've used this method in CentOS, Debian, and Ubuntu, and all of them gave an unrenderable file to the browser when I sent an image without ios::binary. If you look at it with a text viewer, it probably won't have an effect, but looked at with an image viewer, it definitely does.
I would also like to point out that sta...@tntnet isn't mentioned anywhere in the user manual, and should be! Knowing that would have made things easier for me; it took me some time to get my method working! I tried other methods besides f.get() in my implementation, including getline, read, and even the stream operator (although I didn't use rdbuf, I just called f >> str, followed by reply.out() << str) and none of them produced a usable output for me. Binary files always ended up impossible to render when I sent them any way other than one char at a time. I don't know why it is, but since get() worked and the others did not, that's the one I used. And, if this capability is already included... I think that, when responding to things like the TinyMCE discussion from earlier, it would be simpler to direct them to the sta...@tntnet component rather than telling them to compile the .js file. It seems to me that it's much simpler to do things that way than to compile it, when the .js file contains nothing that needs to be dynamically generated. Is there some reason that you've not mentioned this component until now? It's VERY useful information that should have its own section in the documentation, yet isn't even mentioned a single time! Tommi Mäkitalo wrote: > 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 > ------------------------------------------------------------------------------ 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
