On 23.10.2013, at 08:00, Santiago Gala <[email protected]> wrote: > With this caveat, multi byterange support does not look like it is working. > My second test: > > $ curl -v -u admin:admin -H "Range: bytes=0-20,21-63" > http://localhost:8080/index.html > .... > As curl points, the response has no chunk transfer encoding, no > Content-Length, no "Connection: close". This is violation of HTTP, one of > the three things is required or the client gets confused, as you see here > (I had to use Ctrl-C to make the test end).
Ok, you might want to report the issue with multi-byte requests on https://issues.apache.org/jira/browse/SLING, thanks! AFAIK, the code was taken from Apache Tomcat, and was considered stable, but you never know. The common single-range support should work fine though, we use that here. One important use case was html5 video, where browsers use http ranges for progressive streaming, and that works well. > I stilll need to find out if handling of binaries is done > efficiently, without copying to java.io.tmpdir or reading into memory, and > a number of other tests. It does not create a temp file, it uses InputStream.skip() (see StreamRendererServlet#copyRange) to get the ranges, which in case of a FileDataStore in Jackrabbit boils down to a random access on the underlying file. Pretty efficient. > Also, sling has way too many dependencies that are > completely out of scope for our requirements, and getting it trimmed down > to something about the size of jackrabbit would be needed... I understand - if that's the only reason you'd need Sling for, this is probably overkill. You might be able to take the code as an example for a custom servlet. OTOH, if you are doing web app stuff on top of JCR, Sling is really a good option - only Jackrabbit itself, even if it comes with WebDAV and other things, is usually pretty limiting if you want to expose JCR over the web. And RMI is definitely something to avoid over the network. Cheers, Alex
