https://bz.apache.org/bugzilla/show_bug.cgi?id=59288
--- Comment #1 from Christopher Schultz <ch...@christopherschultz.net> --- (In reply to Anita from comment #0) > Problem statement: HTTP sucks for file uploads. > You know it. I know it. ?? > The problems? > > 1. No resuming This isn't a protocol problem; it's a tool problem. HTTP POST theoretically supports the "Range" header. There is a discussion on SO about this: http://stackoverflow.com/questions/1830130/resume-uploads-using-http > 2. POST multipart/form-data bloats the size of the file due to encoding Very little bloat. It's not like it uses base64 encoding or anything like that. > 3. Slow connections typically time out on large files Nothing can fix this. Resumability is the only real cure, and you've listed that one already. > 4. Any server resets or any other network "burps" on the path from client to > server effectively kills the upload Resumability. > 5. People have had moderate success by tuning their webserver and > JSP/Servlet to accept large POSTs, and in general, it works - but not for > everyone and it suffers from everything previously noted. Resumability. > http://tus.io/ > > tus is a new open protocol for resumable uploads built on HTTP. It offers > simple, cheap and reusable stacks for clients and servers to solve the > problem of unreliable file uploads once and for all. Okay, so it trades Content-Length and Range for Upload-Offset and Upload-Length. I suppose this might be better when using old proxies that like to veto odd-looking "standard" requests, but will happily pass-through unrecognized headers. > Currently, there are only two implementations of server side --- Go and > Node.js. I wish the popular server --- Tomcat which is also my favorite can > also implement this new file transfer protocol in the new release version, > too. So... what client is going to bother to implement this? Is the expectation that mostly this will be used by custom mobile clients instead of your run-of-the-mill web browser? -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
