Tips
According to RFC 822, a message header is composed of a field-name followed by a colon (":"), followed by a field-body, and terminated by a carriage-return/line-feed. Field-name is case independent. These rules show a field meta-syntax, without regard for the particular type or internal syntax. Their purpose is to permit detection of fields; also, they present to higher-level parsers an image of each field as fitting on one line.
field = field-name ":" [ field-body ] CRLF
field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
field-body = field-body-contents
[CRLF LWSP-char field-body]
field-body-contents =
<the ASCII characters making up the field-body, as
defined in the following sections, and consisting
of combinations of atom, quoted-string, and
specials tokens, or else consisting of texts>
Header fields are split into four categories and the RFC 2616 defines and contrains some of those headers: General headers, Request headers, Response headers and entity headers.
Description
As a test designer, I shall be able to define constraints on the HTTP header of the HTTP message being validated. In particular, I shall be able to
- restrict the list of allowed field names, or allow the sender to use fields that are not mentioned in the validation profile;
- forbid the usage of a list of field names;
- add constraints on the value of field-body;
As a test designer, I shall not be responsible for including in the validation profile the constraints that are defined in RFC 2616 on specific headers. This responsibility is on the HTTP Validator engine. However, if the specification add more constraints on ones or several of those headers, I shall be able to overide the rules.
For a particular header field, I shall be able to
- For an unstructured field-body:
- Constrain its value to a fix string;
- Constrain its value by referencing a value set the value shall come from;
- Constrain its value using a regular expression;
- Constrain its value by defining a numeric range;
- Say whether it can be multiple valued or not;
- For a structured field-body:
- Define the separator to be used as a delimiter for the different parts of the field-body
- Define the lower and upper limits for the number of allowed repetitions
- If appropriate, define the separator to be used as a delimiter for the repetitions of the field-body
- Give the ordered list of expected elements.
- Assuming that each element of the structured field-body can be see as a key=value parameter, for each parameter of the field-body:
- Give it a name;
- Define whether it is optionnal or required;
- Define whether the key and "=" characters shall appear or not
- Define the value of the key
- Constraint the parameter value with either a fixed string, a regular expression, a reference to a value set, a numeric range.
Example of constraints
According to RFC2616 Section 14.1, the Accept header field is formatted as
Accept = "Accept" ":"
#( media-range [ accept-params ] )
media-range = ( "*/*"
| ( type "/" "*" )
| ( type "/" subtype )
) *( ";" parameter )
accept-params = ";" "q" "=" qvalue *( accept-extension )
accept-extension = ";" token [ "=" ( token | quoted-string ) ]
For the WADO-RS part of DICOM constrains this header field as follows:
Accept - A comma-separated list of representation schemes, in preference order, which will be accepted by the service in the response to this request. The types allowed for this request header are as follows:
- multipart/related; type=application/dicom; [transfer-syntax={TransferSyntaxUID}]
- Specifies that the response can be DICOM Instances encoded in PS3.10 format. If transfer-syntax is not specified the server can freely choose which Transfer Syntax to use for each Instance.
- multipart/related; type=application/octet-stream
- Specifies that the response can be Little Endian uncompressed bulk data.
- multipart/related; type={MediaType}
- Specifies that the response can be pixel data encoded using a {MediaType} listed in Table 6.5-1 (including parameters).
User is interested in receiving JPEG2000 pixel data in lossless or compressed format but is willing to accept JPEG as well.The Accept request would contain the following comma-separated parameters:
Accept: multipart/related=image/dicom+jpx; transfer-syntax=1.2.840.10008.1.2.4.92, multipart/related=image/dicom+jpx; transfer-syntax=1.2.840.10008.1.2.4.93, multipart/related=image/dicom+jpeg
or alternatively, multiple Accept headers:
Accept: multipart/related=image/dicom+jpx; transfer-syntax=1.2.840.10008.1.2.4.92 Accept: multipart/related=image/dicom+jpx; transfer-syntax=1.2.840.10008.1.2.4.93 Accept: multipart/related=application/dicom+jpeg