[tahoe-lafs-trac-stream] [tahoe-lafs] #510: use plain HTTP for storage server protocol

[tahoe-lafs]

#510: use plain HTTP for storage server protocol
------------------------------+---------------------------------
     Reporter:  warner        |      Owner:  zooko
         Type:  enhancement   |     Status:  new
     Priority:  major         |  Milestone:  2.0.0
    Component:  code-storage  |    Version:  1.2.0
   Resolution:                |   Keywords:  standards gsoc http
Launchpad Bug:                |
------------------------------+---------------------------------

Comment (by simeon):

 Replying to [comment:26 zooko]:
 >
 > > Various behaviours relating to Content-Range are forbidden by the
 [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html HTTP 1.1 spec],
 but which one were you referring to?
 >
 > Described here: https://github.com/warner/tahoe-
 lafs/commit/3f6e2f196dc654b8f846b2bc0d174382bf6d59c5#commitcomment-4376374

 AFAIK it is permitted to combine pipelining
 (https://en.wikipedia.org/wiki/HTTP_pipelining) and keep-alive
 (https://en.wikipedia.org/wiki/HTTP_persistent_connection) along with
 content-range, the overhead would not be very great, and perhaps some HTTP
 header fields could be omitted in such a communication.

 I wonder if it's better perhaps to store large files as a series of fixed-
 maximum-size chunks, and have the client do the logic to reassemble them
 ... ? (Haven't read much about your implementation, and actually in my own
 similar work, i originally concluded to opt for simplest usage at client
 end ... so really that comment is not backed by anything, just musing...)

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/510#comment:27>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage