Dell DX6004S DX Object Storage Application Guide - Page 21

HTTP Overview, 3. Requests and Responses

Page 21 highlights

4.2. HTTP Overview The following is paraphrased from the HTTP/1.1 specification. The HTTP protocol is a request/response protocol. A client sends a request to the DX Storage server in the form of a request method, URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and possible body content over a connection with a server. The DX Storage server responds with a status line, including the message's protocol version and a success or error code, followed by a MIME-like message containing server information, entity metadata, and possible entity-body content. Most HTTP communication is initiated by a client application and consists of a request to be applied to a stream on some DX Storage server. In the simplest case, this may be accomplished via a single connection (v) between the client application (CA) and the DX Storage server (S). request chain CA v S response chain SCSP consists of requests that are generated by a DX Storage client (that is, any HTTP/1.1 client) and responses that are generated by one or more nodes in a DX Storage cluster. SCSP requests map to constrained HTTP requests with certain methods, case-insensitive query arguments, and required and optional headers. Similarly, DX Storage responses are valid HTTP responses. 4.3. Requests and Responses Of the eight common methods defined for HTTP requests, SCSP implements five: GET, HEAD, POST, PUT and DELETE. In storage terminology, these map to Read, Info, Write, Update and Delete, as shown in the table in Section 4.1, "Mapping SCSP Operations to HTTP Methods". After DX Storage receives and processes one of these request types, it sends a response back to the client application. A response might be a normal response, a redirect response, or an error response. For convenience, this section lists all responses DX Storage might return to a calling application. This is the same list defined by HTTP/1.1. Note that many of these are not currently returned by DX Storage. However, future releases might use these as defined in the HTTP spec. 4.3.1. HTTP Response Codes 100: "Continue", 101: "Switching", 200: "OK", 201: "Created", 202: "Accepted", 203: "Non-Authoritative Information", 204: "No Content", 205: "Reset Content", 206: "Partial Content", 207: "Multi-Status", 300: "Multiple Choices", 301: "Moved Permanently", Copyright © 2010 Caringo, Inc. All rights reserved 16 Version 5.0 December 2010

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81

Copyright © 2010 Caringo, Inc.
All rights reserved
16
Version 5.0
December 2010
4.2. HTTP Overview
The following is paraphrased from the HTTP/1.1 specification.
The HTTP protocol is a request/response protocol. A client sends a request to the DX Storage
server in the form of a request method, URI, and protocol version, followed by a MIME-like message
containing request modifiers, client information, and possible body content over a connection with a
server. The DX Storage server responds with a status line, including the message's protocol version
and a success or error code, followed by a MIME-like message containing server information, entity
metadata, and possible entity-body content.
Most HTTP communication is initiated by a client application and consists of a request to be applied
to a stream on some DX Storage server. In the simplest case, this may be accomplished via a single
connection (v) between the client application (CA) and the DX Storage server (S).
request chain ------------------------>
CA -------------------v------------------- S
----------------------- response chain
SCSP consists of requests that are generated by a DX Storage client (that is, any HTTP/1.1 client)
and responses that are generated by one or more nodes in a DX Storage cluster. SCSP requests
map to constrained HTTP requests with certain methods, case-insensitive query arguments, and
required and optional headers. Similarly, DX Storage responses are valid HTTP responses.
4.3. Requests and Responses
Of the eight common methods defined for HTTP requests, SCSP implements five: GET, HEAD,
POST, PUT and DELETE. In storage terminology, these map to Read, Info, Write, Update and
Delete, as shown in the table in
Section 4.1, “Mapping SCSP Operations to HTTP Methods”
. After
DX Storage receives and processes one of these request types, it sends a response back to the
client application.
A response might be a normal response, a redirect response, or an error response. For
convenience, this section lists all responses DX Storage might return to a calling application.
This is the same list defined by HTTP/1.1. Note that many of these are not currently returned by DX
Storage. However, future releases might use these as defined in the HTTP spec.
4.3.1. HTTP Response Codes
100: "Continue",
101: "Switching",
200: "OK",
201: "Created",
202: "Accepted",
203: "Non-Authoritative Information",
204: "No Content",
205: "Reset Content",
206: "Partial Content",
207: "Multi-Status",
300: "Multiple Choices",
301: "Moved Permanently",