Re: [Cppcms-users] Front-end http server without upload buffering

[Julian P. <ju...@wh...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok, thanks for your very detailed reply. The environment the HTTP server
will be available in is to be considered a trusted environment, so this
would be OK.
I wrote an own implementation of a static file server as cppcms
application, which should be secure enough (does realpath expansion and
checks it with a configured web-root to make sure that users don't
access any files they shouldn't, only thing is it doesn't check for
symlinks, but as I need them anyway, it would not make sense to check
for them). The missing SSL support is a pity, but as it's a trusted
environment this is ok for now.
I wrote to the Cherokee mailing list to ask them whether uploads are
buffered because it's nowhere in their documentation and hasn't been on
topic on the mailing list so far, but I expect a positive response,
because Cherokee is implemented asynchronously as lighttpd and nginx
are, and there seems to be the need to do that buffering to anticipate
event loop locks.
Are my calculations concerning the disk usage correct? I think lighttpd
stores the uploads in chunks of a certain size (afaik 1M as default, but
you can change it), so the question would be whether it deletes the
files one by one after having send them to the backend application or
whether it deletes all of them after the transmission to backend
application has been completed. In the first case, I could use lighttpd,
because I could spare a few Megabytes for intermediate caching. Only I
don't know how well this behaviour is going to be beared by the flash
memory which has a limited number of write cycles for each of his
blocks, so I see problems in too frequent (and in this case,
unneccessary) file I/O on it, as every firmware would have to be written
two times to flash.
In fact, because of the lack of time and any alternative, I used the
HTTP api of cppcms up to now, but wanted to switch to a proper webserver
because of the remarks in your configuration file overview. After having
read your second email, I think I will stay with cppcms HTTP for now,
and HTTP/1.1 is not needed, because I won't use keep-alive anyway, while
SSL support would be nice, even if it's not desperately needed now.


Thanks,
Julian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJM7Bo9AAoJENidYKvYQHlQvWQQAJjVgBT4pg0zmlJek2yNwDTs
z0i4w54E2vyFrz+07ulE/yYWD2xxDZjkPWW5a5vU3eNrRTJfWyAD32RgN74g7rbM
ycjZ6Qyqp3o6sJwuUVYDxYvM97CEG1dSdMVow7FZb5z9yZPI5XA8mjxoAfagqMxH
w6/rAWMj9sDKBjSV/0apQ77lXW3Ih8kjdy/6CX5ec2UvwnqBvzfbTz7vgkCogg2X
nhzqQeo71lu1YHPck44K8UVA3VsF36ly1OWImZRArnilruPWnRKg/0MkSz8YHwg6
5p02nKQiI9KDd5YMhdMZhj+bHv6o+6gZKkMlOHOT0TpdpW7eVmFHY21aQ+K2xj+F
2wx9BFa72oZmu/a4ABYNjq89Smy7SieK8a5+oyuSbc5kC7U5aRnAjj9ThX33QA9n
ZivqJCB8SM1VtNfc64ZMbqOWOtV+72AiT8l+gXRkbQIbbpiQqlK4r8Di64nNDatv
/Mw/Te1ybO5xySEp9ICMHMTENFlBXphxlc2aEON/8YFGVP8ajyocR1dlejANXKpv
5z7IAHDwz38P833swX5+KIpqLFq26tlhp0+lV1U6QTf2qRDYnX3HNCy1si+k7oSQ
zSP2qYCgOAr2Q+S6K/SkpCJjdzuIXbvtMRBcBs1IvsmiPRaahrWWnwBCPplZGGR+
bnCJMJm8wN4zs3lDac4p
=RUeP
-----END PGP SIGNATURE-----