good afternoon; On 12 Dec 2013, at 12:55 PM, Andy Seaborne wrote:
> On 12/12/13 11:08, Martynas Jusevičius wrote: >> Andy, >> >> speaking of nginx - maybe you happen to know if is possible to limit >> request content size without a Content-Length header? >> >> Martynas > > Don't know - I would not be surprised if it's "can't" because in a stream, > the length isn't known so you can only cleanly reject it (413) by reading up > to the limit without passing it on the intended target function. as this issue has been raised in this venue, it makes sense to describe why this works out this way in a concrete case. mr jusevičius makes requests to a public site. in this situation, even though access is authenticated, there are only limited, somewhat high latency controls on the individual users' behaviour. under which circumstances, despite our clear guidelines, we have too often had imports terminated after dbpedia or equivalent content had been read and cached, because the size was well above the agreed limits. without ascribing intent, it stopped making sense to leave an evident dos vector unmitigated, the content length constraint prior to processing made sense, and it was imposed. it happens, that on the host in question the restriction applies to all accounts (see above). one could supplant the chunking implementation or otherwise count bytes and impose the length limitation on the fly thereby eliminating the header requirement. should use cases demonstrate this to be the best implementation form, this remains an alternative. > > Otherwise, the intended target may see the data start coming in, start > working, send 200 and start to send out it's own stream of results and ... > then have a problem because you can't now send 413. the nginx (or equivalent) cgi support could well - or could well have been implemented to, include protocol agreements with the cgi backend, that it refrain from emitting premature 200's, which would make possible to effect content length control without caching. that is, should a limit be exceeded, nginx could well terminate the processing and emit the 413 autonomously. i have not discovered this to be the case. > > Fuseki streams data in but it's still a transaction (see the "Fuseki v1.0.0 > data import problems" message) because it may fail for some reason e.g parse > error way down the stream. is there any support in the http protocol to negotiate a content-length requirement? evidently, it does not suffice to use the response status to indicate that one is required,. what would happen, if the server were to effect a configuration such that it announces itself as limited to http 1.0? in general, to play dumb is a bad idea, especially where the server would intend to stream results from a query in response to a post request, but i am curious. best regards, from berlin, --- james anderson | [email protected] | http://dydra.com
