You are not logged in.
Pages: 1
Is there a way to limit maximum upload size at the http.sys level? ie. before the Process event is called.
I'm mostly worried about limiting the amount of RAM attempts at large uploads could consume. I'm running a test server on a shoestring RAM budget, literally, think Ikoula's 1€ VMs and wanting to stay below 512 MB RAM
In IIS there are maxRequestLength and maxAllowedContentLength settings, what are the equivalent there? (quickly scanned the Http Server API, but couldn't find how you set them)
Also what about bandwidth limitations? (HttpServerBandwidthProperty)
Any body got experience with them?
Offline
I can't find good solution for this case, so I use nginx in production as frontend (all request to mORMot redirected via proxy_pass directive, static files handled by nginx, upload file size limited by client_max_body_size option). If you found good solution for http.sys - please, post it here.
Offline
I've found a partial (but dirty) workaround by importing HttpCancelHttpRequest from http 2.0, and aborting the request when the headers have been received.
F.i. this will forbid any posts larger than 1kB
if InContentLength<>0 then begin
if InContentLength>1024 then begin
//SendError(412, 'Content-Length too large');
Http.CancelHttpRequest(fReqQueue, Req^.RequestId, nil);
continue;
end;
It's a bit dirty because the request is canceled, so you can't send a response.
The alternative is to just fetch all the content in a rotating buffer and discard everything as it comes in, this allows sending the error response, but then that means your incoming bandwidth will have been eaten, so the cancel may not be that dirty (and you can catch the error on the client side if it's a legit post attempt).
Delving into it, I found Http 2.0 API includes a lot of useful stuff, like kernel-level authentication, static cache, logging, etc.
It ups the requirements to Vista or Windows 2008 though, but looks worth it if you're going to front the server on the wild web (otherwise, it's not too hard to DDOS an HttpAPI 1.0 server by sending in large simultaneous posts that'll keep the THttpApiServer.Execute threads busy eating all the RAM).
Are there any plans to up HttpAPI to 2.0 level?
If so, maybe HttpAPI support it should be taken out of the SynCrtSock unit, so it becomes more easy to pick one or the other by just using the relevant unit.
At a minimum, having an OnHeaderReceived event would be nice, so the above header-related processing could be handled in our code.
Last edited by Eric (2012-12-23 13:31:07)
Offline
I've got it working now, with logs & bandwidth throttling too (haven't tried authentication yet, nor any of the other properties). Most trouble I had was with a MS documentation bug on MSDN.
If you want to have a look, you can find the relevant files in DWScript SVN under Libraries\SimpleServer, though the rest of the demo in the SVN is WIP and doesn't use them yet, once I get everything in working order, I'll commit the rest.
Btw, I made a SetCompressHeader optimization that should be easy to backport (eliminates the temporary string).
Since library can be loaded dynamicaly, we may be able to include both entries if available.
Yes, though the code above currently makes no attempt at distinguishing between v1 & v2.
The snags with supporting both will be a change in the request/response record (they added a couple fields), and having all the v2 functions optional from v1.
That said, the changes from v1 to v2 are rather simple, with some code not requiring any change at all.
Offline
2Eric:
1) please, look on this ticket http://synopse.info/fossil/tktview?name=73da2c17b1 - the same in THttpApi2Server.Execute
2) do you have plane to implement authentication?
and question 2AB&Eric - do you have plane to merge THttpApi2Server realization to mORMot repository? (even without auth on HTTPAPI level it give us ability to solve the problem Chaa temparary solve via RemoteIP in this post http://synopse.info/forum/viewtopic.php?pid=5809#p5809 via THttpApi2Server.connectionID)
Offline
1) good point, eliminated
2) yes, one of the key reason behind the move to http.sys 2.0 is that authentication is supported in the kernel driver (not just faster and less code required, but also less trouble with service/application access rights)
Offline
Pages: 1