IIIF Image API 2.0 - DRAFT
86 |Status of this Document
140 | 141 |This Version: 2.0.0-draft1
142 | 143 |Latest Stable Version: 1.1.0
144 | 145 |Editors:
146 | 147 |-
148 |
- Michael Appleby, Yale University 149 |
- Robert Sanderson, Stanford University 150 |
- Stuart Snydman, Stanford University 151 |
- Jon Stroop, Princeton University 152 |
- Simeon Warner, Cornell University 153 |
Copyright © 2012-2014 Editors and contributors. Published by the IIIF under the CC-BY license.
156 | 157 |158 | 159 |
Abstract
160 | 161 |This document describes an image delivery API proposed by the International Image Interoperability Framework (IIIF) group. The IIIF Image API specifies a web service that returns an image in response to a standard HTTP or HTTPS request. The URI can specify the region, size, rotation, quality characteristics and format of the requested image. A URI can also be constructed to request basic technical information about the image to support client applications. It was conceived of to facilitate systematic reuse of image resources in digital image repositories maintained by cultural heritage organizations. This API could be adopted by any image repository or service, and can be used to retrieve static images in response to a properly constructed URI.
162 | 163 |Please send feedback to iiif-discuss@googlegroups.com
164 | 165 |Table of Contents
166 | 167 |-
168 |
- 1. Audience and Scope 169 |
- 2. URI Syntax
-
170 |
- 2.1. Image Request URI Syntax 171 |
- 2.2. Image Information Request URI Syntax 172 |
174 | - 3. Identifier 175 |
- 4. Image Request Parameters
-
176 |
- 4.1. Region 177 |
- 4.2. Size 178 |
- 4.3. Rotation 179 |
- 4.4. Quality 180 |
- 4.5. Format 181 |
- 4.6. Order of Implementation 182 |
- 4.7. Canonical URI Syntax 183 |
185 | - 5. Information Request
-
186 |
- 5.1. Image Information 187 |
- 5.2 Extensions 188 |
190 | - 6. Compliance Levels 191 |
- 7. Server Responses
-
192 |
- 7.1. Successful Responses 193 |
- 7.2. Error Conditions 194 |
196 | - 8. Authentication 197 |
- 9. URI Encoding and Decoding 198 |
- 10. Security Considerations 199 |
- 11. Appendices
-
200 |
- A. Implementation Notes 201 |
- B. Versioning 202 |
- C. Acknowledgments 203 |
- D. Change Log 204 |
206 |
1. Audience and Scope
209 | 210 |This document is intended for architects and developers building applications that share and consume digital images, particularly from cultural heritage institutions, museums, libraries and archives. Target applications include:
211 | 212 |-
213 |
- Digital image repositories and distributed content networks 214 |
- Image focused web applications, such as pan/zoom viewers, book-readers, etc. 215 |
- Client applications using image content for analysis or comparison 216 |
This specification concerns the use of the images by a client, but not management of the images by the server. It covers how to respond to the requests given in a particular URI syntax, but does not cover methods of implementation such as rotation algorithms, transcoding, color management, compression, or how to respond to URIs that do not conform to the specified syntax. This allows flexibility for implementation in domains with particular constraints or specific community practices, while supporting interoperability in the general case.
219 | 220 |2. URI Syntax
221 | 222 |The IIIF Image API can be called in two ways:
223 | 224 |-
225 |
- Request an image, which may be part of a larger image 226 |
- Request a description of the image characteristics and functionality available for that image 227 |
Both convey the request’s information in the path segments of the URI, rather than as query parameters. This makes responses easier to cache, either at the server or by standard web-caching infrastructure. It also permits a minimal implementation using pre-computed files in a matching directory structure.
230 | 231 |There are four parameters shared by the requests, and other IIIF specifications:
232 | 233 || Name | 237 |Description | 238 |
|---|---|
| scheme | 243 |Indicates the use of the HTTP or HTTPS protocol in calling the service. | 244 |
| server | 247 |The host server on which the service resides. | 248 |
| prefix | 251 |The path on the host server to the service. This prefix is optional, but may be useful when the host server supports multiple services. The prefix may contain multiple path segments, delimited by slashes, but all other special characters must be encoded. See URI Encoding and Decoding for more information. | 252 |
| identifier | 255 |The identifier of the requested image, expressed as a string. This may be an ark, URN, filename, or other identifier. Special characters must be URI encoded. | 256 |
The combination of these parameters forms the image’s Base URI and identifies the underlying image content. It is constructed according to the following URI Template (RFC6570):
261 | 262 |{scheme}://{server}{/prefix}/{identifier}
263 |
264 |
265 | When the base URI is dereferenced, the interaction should result in the Image Information document. It is recommended that the response be a 303 status redirection to the Image Information document’s URI. Implementations may also exhibit other behavior for the base URI beyond the scope of this specification in response to HTTP request headers and methods.
266 | 267 |To allow for extensions, this specification does not define the server behavior when it receives requests that do not match either the Base URI or one of the described URI syntaxes below.
268 | 269 |2.1. Image Request URI Syntax
270 | 271 |The IIIF Image API URI for requesting an image must conform to the following URI Template:
272 | 273 |{scheme}://{server}{/prefix}/{identifier}/{region}/{size}/{rotation}/{quality}.{format}
274 |
275 |
276 | For example:
277 | 278 |http://www.example.org/image-service/abcd1234/full/full/0/default.jpg
279 |
280 |
281 | The sections of the Image Request URI include region, size, rotation, quality and format parameters, which define the characteristics of the returned image. These are described in detail in Image Request Parameters.
282 | 283 |2.2. Image Information Request URI Syntax
284 | 285 |The URI for requesting image information must conform to the following URI Template:
286 | 287 |{scheme}://{server}{/prefix}/{identifier}/info.json
288 |
289 |
290 | For example:
291 | 292 |http://www.example.org/image-service/abcd1234/info.json
293 |
294 |
295 | For each image made available, the server, prefix and identifier components of the information request must be identical to those for the image request described above. The Image Information document is described in detail in the Image Information section.
296 | 297 |3. Identifier
298 | 299 |The API places no restrictions on the form of the identifiers that a server may use or support, although the identifier must be expressed as a string. All special characters (e.g. ? or #) must be URI encoded to avoid unpredictable client behaviors. The URI syntax relies upon slash (/) separators so any slashes in the identifier must be URI encoded (aka. percent-encoded, replace / with %2F ). See the additional discussion in URI Encoding and Decoding.
300 | 301 |4. Image Request Parameters
302 | 303 |All parameters described below are required for compliant construction of a IIIF Image API URI. The sequence of parameters in the URI must be in the order described below. The order of the parameters is also intended as the order of the operations by which the service should manipulate the image content. Thus, the requested image content is first extracted as a region of the complete image, then scaled to the requested size, rotated and transformed into the color depth and format. This resulting image content is returned as the representation for the URI. Image and region dimensions in pixels are always given as an integer numbers. Intermediate calculations may use floating point numbers and the rounding method is implementation specific. Some parameters, notably percentages, may be specified with floating point numbers. These should have at most 10 decimal digits and consist only of decimal digits and “.” with a leading zero if less than 1.
304 | 305 |4.1. Region
306 | 307 |The region parameter defines the rectangular portion of the full image to be returned. Region can be specified by pixel coordinates, percentage or by the value “full”, which specifies that the entire image should be returned.
308 | 309 || Form | 313 |Description | 314 |
|---|---|
full |
319 | The complete image is returned, without any cropping. | 320 |
| x,y,w,h | 323 |The region of the full image to be returned is defined in terms of absolute pixel values. The value of x represents the number of pixels from the 0 position on the horizontal axis. The value of y represents the number of pixels from the 0 position on the vertical axis. Thus the x,y position 0,0 is the upper left-most pixel of the image. w represents the width of the region and h represents the height of the region in pixels. | 324 |
| pct:x,y,w,h | 327 |The region to be returned is specified as a sequence of percentages of the full image’s dimensions, as reported in the Image Information document. Thus, x represents the number of pixels from the 0 position on the horizontal axis, calculated as a percentage of the reported width. w represents the width of the region, also calculated as a percentage of the reported width. The same applies to y and h respectively. These may be floating point numbers. |
328 |
If the request specifies a region which extends beyond the reported dimensions of the full image, then the service should return an image cropped at the image’s edge, rather than adding empty space.
333 | 334 |If the requested region’s height or width is zero, or if the region is entirely outside the bounds of the full image’s reported dimensions, then the server should return a 400 status code.
335 | 336 |Examples:
337 | 338 |
342 |
343 | 1 size=full 344 |
|
346 |
347 |
348 | 2 region=125,15,120,140 349 |
|
351 |
354 |
355 | 3 region=pct:41.6,7.5,40,70 356 |
|
358 |
359 |
360 | 4 region=125,15,200,200 361 |
N.B. Returned image is 175,185 px 363 | |
364 |
367 |
368 | 5 region=pct:41.6,7.5,66.6,100 369 |
N.B. Returned image is 175,185 px 371 | |
372 | 373 | |
4.2. Size
378 | 379 |The size parameter determines the dimensions to which the extracted region is to be scaled.
380 | 381 || Form | 385 |Description | 386 |
|---|---|
full |
391 | The extracted region is not scaled, and is returned at its full size. | 392 |
| w, | 395 |The extracted region should be scaled so that its width is exactly equal to w, and the height will be a calculated value that maintains the aspect ratio of the requested region. | 396 |
| ,h | 399 |The extracted region should be scaled so that its height is exactly equal to h, and the width will be a calculated value that maintains the aspect ratio of the requested region. | 400 |
| pct:n | 403 |The width and height of the returned image is scaled to n% of the width and height of the extracted region. The aspect ratio of the returned image is the same as that of the extracted region. | 404 |
| w,h | 407 |The width and height of the returned image are exactly w and h. The aspect ratio of the returned image may be different than the extracted region, resulting in a distorted image. | 408 |
| !w,h | 411 |The image content is scaled for the best fit such that the resulting width and height are less than or equal to the requested width and height. The exact scaling may be determined by the service provider, based on characteristics including image quality and system performance. The dimensions of the returned image content are calculated to maintain the aspect ratio of the extracted region. | 412 |
If the resulting height or width is zero, then the server should return a 400 (bad request) status code.
417 | 418 |The image server may support scaling beyond the full size of the extracted region.
419 | 420 |Examples:
421 | 422 |
426 |
427 | 1 size=full 428 |
|
430 |
431 |
432 | 2 size=150, 433 |
|
435 |
436 |
437 | 3 size=,150 438 |
|
440 |
443 |
444 | 4 size=pct:50 445 |
|
447 |
448 |
449 | 5 size=225,100 450 |
|
452 |
453 |
454 | 6 size=!225,100 455 |
N.B. Returned image is 150,100 px 457 | |
458 |
4.3. Rotation
463 | 464 |The rotation value represents the number of degrees of clockwise rotation from the original, and may be any floating point number from 0 to 360.
465 | 466 || Form | 470 |Description | 471 |
|---|---|
| n | 476 |The degrees of clockwise rotation from the original, from 0 up to 360. | 477 |
A rotation value that is out of range or unsupported should result in a 400 status code.
482 | 483 |In most cases a rotation will change the width and height dimensions of the returned image. The service should return an image that contains all of the image contents requested in the region and size parameters, even if the dimensions of the returned image file are different than specified in the size parameter. The image contents should not be scaled as a result of the rotation, and there should be no additional space between the corners of the rotated image contents and the bounding box of the returned image content.
484 | 485 |For non-90-degree rotations the API does not specify the background color.
486 | 487 |Examples:
488 | 489 |
493 |
494 | 1 rotation=0 495 |
|
497 |
498 |
499 | 2 rotation=180 500 |
|
502 |
505 |
506 | 3 rotation=90 507 |
|
509 |
510 |
511 | 4 rotation=22.5 512 |
|
514 |
4.4. Quality
519 | 520 |The quality parameter determines whether the image is delivered in color, grayscale or black and white.
521 | 522 || Quality | 526 |Parameter Returned | 527 |
|---|---|
default |
532 | The image is returned using the server’s default quality (e.g. color, gray or bitonal as below) for the image. | 533 |
color |
536 | The image is returned in full color. | 537 |
gray |
540 | The image is returned in grayscale, where each pixel is black, white or any shade of gray in between. | 541 |
bitonal |
544 | The image returned is bitonal, where each pixel is either black or white. | 545 |
A quality value that is unsupported should result in a 400 status code.
550 | 551 |Examples:
552 | 553 |
557 |
558 | 1 quality=default 559 |
|
561 |
562 |
563 | 2 quality=color 564 |
|
566 |
569 |
570 | 3 quality=gray 571 |
|
573 |
574 |
575 | 4 quality=bitonal 576 |
|
578 |
4.5. Format
583 | 584 |The format of the returned image is expressed as an extension at the end of the URI.
585 | 586 || Extension | 590 |MIME Type | 591 |
|---|---|
jpg |
596 | image/jpeg | 597 |
tif |
600 | image/tiff | 601 |
png |
604 | image/png | 605 |
gif |
608 | image/gif | 609 |
jp2 |
612 | image/jp2 | 613 |
pdf |
616 | application/pdf | 617 |
A format value that is unsupported should result in a 400 status code.
622 | 623 |Examples:
624 | 625 |-
626 |
.../full/full/0/default.jpg
627 | .../full/full/0/default.png
628 | .../full/full/0/default.tif
629 |
4.6. Order of Implementation
632 | 633 |The sequence of parameters in the URI is intended to express the order in which image manipulations are made against the full image content. This is important to consider when implementing the service because applying the same parameters in a different sequence will often result in a different image being delivered. The order is critical so that the application calling the service reliably receives the output it expects.
634 | 635 |The parameters should be interpreted as if the the sequence of image manipulations were:
636 | 637 |Region THEN Size THEN Rotation THEN Quality THEN Format
643 |
644 | 1 region=125,15,120,140 size=90, rotation=345 quality=gray 645 |
|
647 |
4.7. Canonical URI Syntax
652 | 653 |There are several reasons why a canonical URI syntax is desirable:
654 | 655 |-
656 |
- It enables static, file-system based implementations, which will have only a single URI at which the content is available. 657 |
- Caching becomes significantly more efficient, both client and server side, when the URIs used are the same between systems and sessions. 658 |
- Response times can be improved by avoiding redirects from a requested non-canonical URI syntax to the canonical syntax by using the canonical form directly 659 |
In order to support the above requirements, clients should construct the image request URIs using to following canonical parameter values where possible.
662 | 663 || Parameter | 667 |Canonical value | 668 |
|---|---|
| region | 673 |“full” if the whole image is requested, otherwise the x,y,w,h description of the region. | 674 |
| size | 677 |“full” if the default size is requested, otherwise the pixel dimensions w,h. | 678 |
| rotation | 681 |An integer if possible, and trimming any trailing zeros in a decimal value, and a leading 0 if the value is below 1. | 682 |
| quality | 685 |“default” unless a quality that is different from the default quality is requested. | 686 |
| format | 689 |Explicit format string required; ‘jpg’ is preferred. | 690 |
When the client requests an image, the server may add a link header to the response that indicates the canonical URI for that request:
695 | 696 |Link: <http://iiif.example.com/server/full/full/0/default.jpg>;rel="canonical"
697 |
698 |
699 | 5. Information Request
700 | 701 |The Image Information document contains both metadata about the image, such as full height and width, and functionality available for it, such as the formats in which it may be retrieved. The service must return this information about the image. The request for technical information must conform to the URI Template:
702 | 703 |{scheme}://{server}{/prefix}/{identifier}/info.json
704 |
705 |
706 | The syntax for the response is JSON-LD. The content-type of the response must be either “application/json” (regular JSON), or “application/ld+json” (JSON-LD). If the client explicitly wants the JSON-LD content-type, then it must specify this in an Accept header, otherwise the server must return the regular JSON content-type.
707 | 708 |If the regular JSON content-type is returned, then it is recommended that the server provide a link header to the context document. The syntax for the link header is below, and further described in section 6.8 of the JSON-LD specification. If the client requests “application/ld+json”, the link header may still be included but must be ignored. The entity body is identical regardless of the content-type, including the @context field.
Link: <http://iiif.io/api/image/2/context.json>
711 | ; rel="http://www.w3.org/ns/json-ld#context"
712 | ; type="application/ld+json"
713 |
714 |
715 | Servers should send the Access-Control-Allow-Origin header with the value * in response to information requests. The syntax is shown below and is described in the CORS specification. This header is required in order to allow the JSON responses to be used by Web applications hosted on different servers.
Access-Control-Allow-Origin: *
718 |
719 |
720 | 5.1. Image Information
721 | 722 |The JSON in the response will include the following properties:
723 | 724 || Property | 728 |Required? | 729 |Description | 730 |
|---|---|---|
@context |
735 | Required | 736 |The context document that describes the semantics of the terms used in the document. This must be the URI: http://iiif.io/api/image/2.0/context.json for version 2.0 of the IIIF Image API. This document allows the response to be interpreted as RDF, using the JSON-LD serialization. |
737 |
@id |
740 | Required | 741 |The Base URI of the image (as defined in URI Syntax, including scheme, server, prefix and identifier without a trailing slash. | 742 |
width |
745 | Required | 746 |The width of the full image. | 747 |
height |
750 | Required | 751 |The height of the full image. | 752 |
protocol |
755 | Required | 756 |The URI http://iiif.io/api/image which can be used to determine that the document describes an image service which is a version of the IIIF Image API. |
757 |
profile |
760 | Required | 761 |An array of profiles, indicated by either a URI or an object describing the features supported. The first entry in the array must be a compliance level URI, as defined below. | 762 |
| scale_factors | 765 |Optional | 766 |Some image servers support the creation of multiple resolution levels for a single image in order to optimize the efficiency in delivering images of different sizes. The scale_factors property expresses a set of resolution scaling factors. For example, a scale factor of 4 indicates that the service can efficiently deliver images at 1/4 or 25% of the height and width of the full image. |
767 |
sizes |
770 | Optional | 771 |A set of dimensions that the server has available, expressed in the “w,h” syntax. This may be used to let a client know the sizes that are available when the server does not support requests for arbitrary sizes, or simply as a hint that requesting an image of this size may result in a faster response. | 772 |
tile_width |
775 | Optional | 776 |Some image servers efficiently support delivery of predefined tiles enabling easy assembly of portions of the image. It is assumed that the same tile sizes are used for all scale factors supported. The tile_width property expresses the width of the predefined tiles. |
777 |
tile_height |
780 | Optional | 781 |The tile_height property expresses the height of the predefined tiles. See description of tile_width for more information. |
782 |
Image profiles have the following properties:
787 | 788 || Property | 792 |Required? | 793 |Description | 794 |
|---|---|---|
formats |
799 | Optional | 800 |The set of image format parameter values available for the image. | 801 |
qualities |
804 | Optional | 805 |The set of image quality parameter values available for the image. | 806 |
supports |
809 | Optional | 810 |The set of additional features supported beyond those declared in the compliance level document | 811 |
The set of features that may be specified in the supports property of an Image profile are:
| Feature Name | 821 |Description | 822 |
|---|---|
base_uri_redirect |
827 | The base URI of the service will redirect to the Image Information document | 828 |
canonical_link_header |
831 | The canonical image URI HTTP link header is provided on image responses | 832 |
cors |
835 | The CORS HTTP header is provided on all responses | 836 |
jsonld_media_type |
839 | The JSON-LD media type is provided when JSON-LD is requested | 840 |
profile_link_header |
843 | The profile link header is provided on image responses | 844 |
region_by_pct |
847 | Regions of images may be requested by percentage | 848 |
region_by_px |
851 | Regions of images may be requested by pixel dimensions | 852 |
rotation_arbitrary |
855 | Rotation of images may be requested by degrees other than multiples of 90 | 856 |
rotation_by_90s |
859 | Rotation of images may be requested by degrees in multiples of 90 | 860 |
size_above_full |
863 | Size of images may be requested larger than the “full” size | 864 |
size_by_forced_wh |
867 | Size of images may be requested in the form “!w,h” | 868 |
size_by_h |
871 | Size of images may be requested in the form “,h” | 872 |
size_by_pct |
875 | Size of images may be requested in the form “pct:n” | 876 |
size_by_w |
879 | Size of images may be requested in the form “w,” | 880 |
size_by_wh |
883 | Size of images may be requested in the form “w,h” | 884 |
The set of features, formats and qualities supported is the union of those declared in all of the external profile documents and any embedded profile objects. If a property is not present in either the profile document or the supports property of an embedded profile, then a client must assume that the feature is not supported.
The JSON response must conform to the structure shown in the following example:
891 | 892 |{
894 | "@context" : "http://iiif.io/api/image/2/context.json",
895 | "@id" : "http://www.example.org/image-service/abcd1234/1E34750D-38DB-4825-A38A-B60A345E591C",
896 | "protocol" : "http://iiif.io/api/image",
897 | "width" : 6000,
898 | "height" : 4000,
899 | "scale_factors" : [ 1, 2, 4 ],
900 | "sizes" : [ "150,100", "360,240", "3600,2400" ],
901 | "tile_width" : 1024,
902 | "tile_height" : 1024,
903 | "profile" : [
904 | "http://iiif.io/api/image/2/level2.json",
905 | {
906 | "formats" : [ "jpg", "png" ],
907 | "qualities" : [ "default" ],
908 | "supports" : [
909 | "canonical_link_header", "rotation_arbitrary"
910 | ]
911 | }
912 | ]
913 | }
914 | 5.2 Extensions
917 | 918 |Local additions to the image information document may be specified in two ways:
919 | 920 |-
921 |
- Extra properties may be added to the document to provide information not defined in this specification. Clients must ignore properties that are not understood. 922 |
- URIs may be added to the supports list of a profile to cover features not defined in this specification, and similarly clients must ignore URIs that are not understood. 923 |
{
927 | "@context" : "http://iiif.io/api/image/2/context.json",
928 | // ...
929 | "documentation" : "http://www.example.com/my/documentation.html",
930 | // ...
931 | "profile" : [
932 | "http://iiif.io/api/image/2/level2.json",
933 | "http://www.example.com/my/profile-level-42.json",
934 | {"supports" : ["http://www.example.com/my/feature.html"]}
935 | ]
936 | }
937 | 6. Compliance Levels
940 | 941 |The Image Information document must specify the extent to which the API is supported by including a compliance level URI as the first entry in the profile property. This URI links to a description of the highest compliance level for which all requirements are met. The URI must be one of those given in Image API Compliance. This description contains the profile related features, as discussed in Image Information. A server may declare different compliance levels for different images.
The compliance level URI may also be given in the HTTP Link header (RFC5988) with the parameter rel="profile", and thus a complete header might look like:
Link: <http://iiif.io/api/image/2/level1.json>;rel="profile"
946 |
947 |
948 | 7. Server Responses
949 | 950 |7.1. Successful Responses
951 | 952 |Servers may transmit HTTP responses with 200 (Successful) or 3xx (Redirect) status codes when the request has been successfully processed. If the status code is 200, then the entity-body must be the requested image or information response. If the status code is 301, 302, 303, or 304, then the entity-body is unrestricted, but it is recommended to be empty. If the status code is 301, 302, or 303 then the Location HTTP Header must be set containing the URI of the image that fulfills the request. This enables servers to have a single canonical URI to promote caching of responses. Status code 304 is handled exactly as per the HTTP specification. Clients should expect to encounter all of these situations and must not assume that the entity-body of the initial response necessarily contains the image data.
953 | 954 |7.2. Error Conditions
955 | 956 |The order in which servers parse requests and detect errors is not specified. A request is likely to fail on the first error encountered and return an appropriate HTTP status code, with common codes given in the list below. It is recommended that the body of the error response includes a human-readable description of the error in either plain text or html.
957 | 958 || Status Code | 962 |Description | 963 |
|---|---|
| 400 Bad Request | 968 |This response is used when it is impossible for the server to fulfil the request, as the syntax of the request is incorrect. For example, this would be used if the size parameter does not match any of the specified syntaxes. | 969 |
| 401 Unauthorized | 972 |Authentication is required and not provided. See Section 7 below for details. | 973 |
| 403 Forbidden | 976 |The user, authenticated or not, is not permitted to perform the requested operation. | 977 |
| 404 Not Found | 980 |The image resource specified by identifier does not exist, or the value of one or more of the parameters is not supported for this image. | 981 |
| 500 Internal Server Error | 984 |The server encountered an unexpected error that prevented it from fulfilling the request. | 985 |
| 501 Not Implemented | 988 |A valid IIIF request that is not implemented by this server. | 989 |
| 503 Service Unavailable | 992 |Used when the server is busy/temporarily unavailable due to load/maintenance issues. An alternative to connection refusal with the option to specify a back-off period. | 993 |
8. Authentication
998 | 999 |This API does not specify whether the image server will support authentication or what mechanism it might use. In the case of “401 Unauthorized” HTTP response, the content of the WWW-Authenticate header will depend on the authentication mechanism supported by the server. If the server supports HTTP Basic or Digest authentication then the header should follow RFC2617, for example:
1000 | 1001 |WWW-Authenticate: Basic realm="Images"
1002 |
1003 |
1004 | 9. URI Encoding and Decoding
1005 | 1006 |The URI syntax of this API relies upon slash (/) separators which must not be encoded. Clients must percent-encode special characters (the to-encode set below: percent and gen-delims of RFC3986 except the colon) within the components of requests. For example, any slashes within the identifier part of the URI must be percent-encoded. Encoding is necessary only for the identifier because other components will not include special characters.
1007 | 1008 |to-encode = "/" / "?" / "#" / "[" / "]" / "@" / "%"
1009 |
1010 |
1011 | Upon receiving an API request, a server must first split the URI path on slashes and then decode any percent-encoded characters in each component.
1012 | 1013 |Additionally, if identifiers include any characters outside the US-ASCII set then the encoding to octets must be defined consistently on client and server, and the octets must be percent-encoded. Percent-encoding other characters introduces no ambiguity but is unnecessary.
1014 | 1015 || Parameters | 1019 |URI path | 1020 |
|---|---|
| identifier=id1 region=full size=full rotation=0 quality=default | 1025 |id1/full/full/0/default |
1026 |
| identifier=id1 region=0,10,100,200 size=pct:50 rotation=90 quality=default format=png | 1029 |id1/0,10,100,200/pct:50/90/default.png |
1030 |
| identifier=id1 region=pct:10,10,80,80 size=50, rotation=22.5 quality=color format=jpg | 1033 |id1/pct:10,10,80,80/50,/22.5/color.jpg |
1034 |
| identifier=bb157hs6068 region=full size=full rotation=270 quality=gray format=jpg | 1037 |bb157hs6068/full/full/270/gray.jpg |
1038 |
| identifier=ark:/12025/654xz321 region=full size=full rotation=0 quality=default | 1041 |ark:%2F12025%2F654xz321/full/full/0/default |
1042 |
| identifier=urn:foo:a123,456 region=full size=full rotation=0 quality=default | 1045 |urn:foo:a123,456/full/full/0/default |
1046 |
| identifier=urn:sici:1046-8188(199501)13:1%3C69:FTTHBI%3E2.0.TX;2-4 region=full size=full rotation=0 quality=default | 1049 |urn:sici:1046-8188(199501)13:1%253C69:FTTHBI%253E2.0.TX;2-4/full/full/0/default |
1050 |
| identifier=http://example.com/?54#a region=full size=full rotation=0 quality=default | 1053 |http:%2F%2Fexample.com%2F%3F54%23a/full/full/0/default |
1054 |
Servers which are incapable of processing arbitrarily encoded identifiers should make their best efforts to expose only image identifiers for which clients will not encode any of the characters, and thus it is recommended to limit characters in identifiers to letters, numbers and the underscore character.
1059 | 1060 |10. Security Considerations
1061 | 1062 |This API defines a URI syntax and the semantics associated with its components. The composition of URIs has few security considerations except possible exposure of sensitive information in URIs or revealing of browse/view behavior of users.
1063 | 1064 |Server applications implementing this API should consider possible denial-of-service attacks, and authentication vulnerabilities based on DNS spoofing. Applications must be careful to parse incoming requests (URIs) in ways that avoid overflow or injection attacks.
1065 | 1066 |Early sanity checking of URIs (lengths, trailing GET, invalid characters, out-of-range parameters) and rejection with appropriate response codes is recommended.
1067 | 1068 |11. Appendices
1069 | 1070 |A. Implementation Notes
1071 | 1072 |-
1073 |
- For use cases that enable the saving of the image, it is recommended to use the HTTP
Content-Dispositionheader (RFC6266) to provide a convenient filename that distinguishes the image, based on the identifier and parameters provided.
1074 | - This specification makes no assertion about the rights status of requested images or any other descriptive metadata, whether or not authentication has been accomplished. Please see the IIIF Presentation API for rights and other information. 1075 |
- This API does not specify how image servers fulfill requests, what quality the returned images will have for different parameters, or how parameters may affect performance. 1076 |
- Image identifiers that include the slash (/ %2F) or backslash (\ %5C) characters may cause problems with some HTTP servers. Apache servers from version 2.2.18 support the
AllowEncodedSlashes NoDecodeconfiguration directive which will correctly pass these characters to client applications without rejecting or decoding them. Servers using older versions of Apache and local identifiers which include these characters will need to use a workaround such as internally translating or escaping slash and backslash to safe value (perhaps by double URI-encoding them).
1077 | - As described in Rotation, in order to retain the size of the requested image contents, rotation will change the width and height dimensions of the returned image file. A formula for calculating the dimensions of the returned image file for a given rotation can be found here. 1078 |
B. Versioning
1081 | 1082 |Starting with version 2.0, this specification follows Semantic Versioning. See the note Versioning of APIs for details regarding how this is implemented.
1083 | 1084 |C. Acknowledgments
1085 | 1086 |The production of this document was generously supported by a grant from the Andrew W. Mellon Foundation.
1087 | 1088 |Many thanks to Ben Albritton, Matthieu Bonicel, Anatol Broder, Kevin Clarke, Tom Cramer, Ian Davis, Neil Jefferies, Scotty Logan, Sean Martin, Roger Mathisen, Lynn McRae, Willy Mene, Mark Patton, Petter Rønningsen, and Brian Tingle for your thoughtful contributions to the effort and written feedback. Thanks also to the members of the IIIF Community for their continuous engagement, innovative ideas and feedback.
1089 | 1090 |D. Change Log
1091 | 1092 || Date | 1096 |Description | 1097 |
|---|---|
| 2014-05-XX | 1102 |Version 2.0 (Voodoo Bunny) RFC View change log | 1103 |
| 2013-09-17 | 1106 |Version 1.1 released. | 1107 |
| 2013-09-04 | 1110 |Added @context to Image Information Request table in section 5. | 1111 |
| 2013-06-26 | 1114 |Changed quality parameter definitions in section 4.4. | 1115 |
| 2013-06-17 | 1118 |Draft release 1.1. View change log. | 1119 |
| 2012-08-10 | 1122 |Release 1.0 | 1123 |
| 2012-07-13 | 1126 |Incorporates responses to RFC feedback | 1127 |
| 2012-03-09 | 1130 |Initial release | 1131 |
| 2012-04-13 | 1134 |0.2 after internal review and IIIF April Meeting | 1135 |
| 2012-05-02 | 1138 |RFC version | 1139 |
343 |
348 |
355 |
360 |
368 |
432 |
437 |
444 |
449 |
454 |
499 |
506 |
511 |
570 |
575 |
644 |