TEXT   45

HTTP Message Bodies

Guest on 20th May 2022 08:51:56 AM

  1. Arenas as HTTP Message Bodies
  3.     Use a PUT request includng the message handle as the start line.
  4.     Don't use multi-part mime as it is delimited rather than counted.
  5.     Omit the Host header.
  6.     Add an extra CRLF after the request BODY.
  8.         PUT /?h=HANDLE HTTP/1.1\r\n
  9.         Content-Type: application/octet-stream\r\n
  10.         Content-Length: 4\r\n
  11.         \r\n
  12.         BODY\r\n
  14. An arena file may contain multiple parts, each starts with a "PUT"
  15. request start line, followed by a partial header, a CRLF, a BODY and
  16. a extra CRLF. The Host field header line is omitted so that the file is
  17. more portable.
  19. Note that the BODY is followed by an extra CRLF, even though the HTTP/1.1
  20. standard does not expect or allow a CRLF between the end of the BODY
  21. and the next request. The Host header field is also omitted even though
  22. it is required by the HTTP/1.1 protocol. In this way, the arena is not
  23. a 100% record of the request history suitable for unmediated replay,
  24. but rather a collection of salient information.
  26. The Content-Type header field is optional. If a Content-Type header is not
  27. present, the type application/octet-stream may be assumed, but is not
  28. For a simple immutable object store, the sender MUST compute a sha256
  29. hash over the following header fields  and body and use a hex encoding
  30. of a 16B-32B prefix of the hexadecimal encoding of the hash (as 32B-48B)
  31. for the handle. If the resource is compressed, the handle is computed
  32. as a prefix of the hash over the following header fields, plus CRLF,
  33. plus compressed/encoded body, omitting the extra trailing CRLF.
  34. added for the purpose of handle generation nor in a GET response.
  36. A Content-Encoding header may be supported in the future. If so, it
  37. represents an encoding (e.g. deflate) applied to the underlying resource
  38. to generate the encoded BODY. If present it should follow any Content-Type
  39. field and preceed the Content-Length for the handle hash computation.
  41. The Content-Length header field is required and determines the length of
  42. the encoded resource BODY as opaque bytes. It SHOULD be the last field
  43. of the header.
  45. If no Content-Type or Content-Encoding is specified, the handle is
  46. computed using just the Content-Length header, CRLF, and the opaque
  47. bytes body.
  49. An origin server SHOULD verify the handle hash before processing a PUT
  50. request.
  52. https://tools.ietf.org/html/rfc3864#section-4.1
  54. Thus, for maximum flexibility, header field names SHOULD further be
  55. restricted to just letters, digits, hyphen ('-') and underscore ('_')
  56. characters, with the first character being a letter or underscore.
  58. Arena Delta Index
  60.     '#arena-delta-index' CRLF \
  61.     'fid:' SP FID CRLF \
  62.     [ 'also:' SP FID *( ',' FID ) CRLF ] \
  63.     CRLF \
  64.     *( HANDLE SP FIRST '-' LAST CRLF )
  67. Blob Fragment Tree
  69.     A frag-tree (fragment tree) node specifies an interior or root node
  70.     of tree that maps to fragments holding bytes in a virtual address
  71.     space. Normally they will be contiguous blocks, but voids are allowed.
  72.     Child elements are referenced by HANDLE or URI and may be of type
  73.     application/octet-stream for leaf byte blocks or application/x-qv
  74.     for other frag-tree nodes.
  76.         '#frag-tree' [ SP MAJOR '.' MINOR ] CRLF \
  77.         [ 'frag-size:' SP COUNT CRLF ] \
  78.         [ 'level:' SP COUNT CRLF ] \
  79.         [ 'size:' SP COUNT CRLF ] \
  80.         CRLF \
  81.         *( HANDLE [ SP FIRST [ '-' LAST ] ] CRLF )
  83.     If all fragments (possibly excluding the last one) are of a known
  84.     fixed-size, the frag-size field MAY be used to specify that size.
  86.     If the level of the node in the frag-tree is known, it MAY be
  87.     specifed in the level field. If specified, the level MUST be greater
  88.     than the level of any child node and can be zero only if all child
  89.     blocks are not frag-tree nodes.
  91.     The RELATIVE size of the virtual leaf block list SHOULD be specified
  92.     in the size field if it is known in advance. It normally is one
  93.     greater than the LAST byte of the last child, unless the virtual
  94.     region ends with a void.
  96.     Each line of the body holds the handle of a child node and optionally
  97.     specifes the RELATIVE offset of the FIRST or first and LAST bytes
  98.     of the region it covers.
  100.     The offsets are RELATIVE to the logical start of the virtual space,
  101.     rather than absolute, so that a frag-tree could be reused for another
  102.     region of a larger virtual space, or logically shifted to accomodate
  103.     insertions or deletions.
  105.     If no offsets are specified, but a fixed frag-size if listed,
  106.     then each child region is assumed to start at a computed offset
  107.     dependent on the number of fragments that preceed it. If no offsets
  108.     are specified and a fragsize is not specified, the child
  109.     fragments/regions are catenated together to form a virtual byte
  110.     stream for sequential read access and fragment offsets are not
  111.     directly available for random access.
  114. Directory Manifest
  116.     #directory-manifest CRLF \
  117.     CRLF \
  118.     *( %FILENAME SP 'f=' FTYPE ', h=' HANDLE ', m=' MTIME ', s=' SIZE CRLF )
  120.     Optional u=USER, g=GROUP, ...
  122.     If a directory gets too big, it is broken into parts by a suffix
  123.     of the hash on the filenames. While each part is larger than 8192,
  124.     look for names whose hashtail&0x1fff == 0 and split; if still too big,
  125.     shrink the mask by 1 bit and repeat.
  127.     #directory-manifest-indirect \
  128.     'level:' SP COUNT CRLF \ \
  129.     CRLF
  132.     If the indirect nodes are too big, repeat spliting the level.
  134.     For the name suffix hash, prefix the (utf8) filename with a 4 digit
  135.     hex level number plus a colon, so that the hashes differ for each
  136.     level. e.g.
  138.         b'0000:FILENAME'
  139.         b'0001:FILENAME'
  140.         b'0002:FILENAME'
  143. GET
  145. The GET method requests transfer of a current selected representation
  146. for the target resource.  GET is the primary mechanism of information
  147. retrieval and the focus of almost all performance optimizations.  Hence,
  148. when people speak of retrieving some identifiable information via HTTP,
  149. they are generally referring to making a GET request.
  151. A client can alter the semantics of GET to be a "range request",
  152. requesting transfer of only some part(s) of the selected representation,
  153. by sending a Range header field in the request ([RFC7233]).
  156. HEAD
  158. The HEAD method is identical to GET except that the server MUST NOT send
  159. a message body in the response (i.e., the response terminates at the end
  160. of the header section). The server SHOULD send the same header fields
  161. in response to a HEAD request as it would have sent if the request had
  162. been a GET, except that the payload header fields (Section 3.3) MAY
  163. be omitted. This method can be used for obtaining metadata about the
  164. selected representation without transferring the representation data and
  165. is often used for testing hypertext links for validity, accessibility,
  166. and recent modification.
  169. POST
  171. If one or more resources has been created on the origin server as a
  172. result of successfully processing a POST request, the origin server
  173. SHOULD send a 201 (Created) response containing a Location header field
  174. that provides an identifier for the primary resource created (Section
  175. 7.1.2) and a representation that describes the status of the request
  176. while referring to the new resource(s).
  178. For cases where an origin server wishes the client to be able to cache
  179. the result of a POST in a way that can be reused by a later GET, the
  180. origin server MAY send a 200 (OK) response containing the result and
  181. a Content-Location header field that has the same value as the POST's
  182. effective request URI (Section
  184. If the result of processing a POST would be equivalent to a representation
  185. of an existing resource, an origin server MAY redirect the user agent to
  186. that resource by sending a 303 (See Other) response with the existing
  187. resource's identifier in the Location field. This has the benefits
  188. of providing the user agent a resource identifier and transferring the
  189. representation via a method more amenable to shared caching, though at
  190. the cost of an extra request if the user agent does not already have
  191. the representation cached.
  194. PUT
  196. The PUT method requests that the state of the target resource be created
  197. or replaced with the state defined by the representation enclosed in the
  198. request message payload. A successful PUT of a given representation would
  199. suggest that a subsequent GET on that same target resource will result in
  200. an equivalent representation being sent in a 200 (OK) response. However,
  201. there is no guarantee that such a state change will be observable, since
  202. the target resource might be acted upon by other user agents in parallel,
  203. or might be subject to dynamic processing by the origin server, before
  204. any subsequent GET is received. A successful response only implies that
  205. the user agent's intent was achieved at the time of its processing by
  206. the origin server.
  208. If the target resource does not have a current representation and the
  209. PUT successfully creates one, then the origin server MUST inform the user
  210. agent by sending a 201 (Created) response. If the target resource does
  211. have a current representation and that representation is successfully
  212. modified in accordance with the state of the enclosed representation,
  213. then the origin server MUST send either a 200 (OK) or a 204 (No Content)
  214. response to indicate successful completion of the request.
  216. An origin server SHOULD ignore unrecognized header fields received in
  217. a PUT request (i.e., do not save them as part of the resource state).
  219. An origin server SHOULD verify that the PUT representation is consistent
  220. with any constraints the server has for the target resource that cannot or
  221. will not be changed by the PUT. This is particularly important when the
  222. origin server uses internal configuration information related to the URI
  223. in order to set the values for representation metadata on GET responses.
  224. When a PUT representation is inconsistent with the target resource,
  225. the origin server SHOULD either make them consistent, by transforming
  226. the representation or changing the resource configuration, or respond
  227. with an appropriate error message containing sufficient information
  228. to explain why the representation is unsuitable. The 409 (Conflict)
  229. or 415 (Unsupported Media Type) status codes are suggested, with the
  230. latter being specific to constraints on Content-Type values.
  232. DELETE
  234. The DELETE method requests that the origin server remove the association
  235. between the target resource and its current functionality. In effect,
  236. this method is similar to the rm command in UNIX: it expresses a
  237. deletion operation on the URI mapping of the origin server rather than
  238. an expectation that the previously associated information be deleted.
  240. 4.2. Authorization
  242. The "Authorization" header field allows a user agent to authenticate
  243. itself with an origin server -- usually, but not necessarily, after
  244. receiving a 401 (Unauthorized) response. Its value consists of
  245. credentials containing the authentication information of the user agent
  246. for the realm of the resource being requested.
  248.      Authorization = credentials
  250. If a request is authenticated and a realm specified, the same credentials
  251. are presumed to be valid for all other requests within this realm
  252. (assuming that the authentication scheme itself does not require
  253. otherwise, such as credentials that vary according to a challenge value
  254. or using synchronized clocks).
  256. A proxy forwarding a request MUST NOT modify any Authorization fields
  257. in that request. See Section 3.2 of [RFC7234] for details of and
  258. requirements pertaining to handling of the Authorization field by
  259. HTTP caches.

Raw Paste

Login or Register to edit or fork this paste. It's free.