메뉴
Amazon Simple Storage Service
개발자 안내서 (API Version 2006-03-01)

HTML 양식(AWS 서명 버전 2)

Amazon S3와 통신할 때 일반적으로 REST 또는 SOAP API를 사용하여 put, get, delete 등의 작업을 수행합니다. SOAP API를 처리하거나 REST PUT 요청을 만들 수 없는 브라우저의 경우, POST를 사용하여 브라우저를 통해 곧바로 Amazon S3에 데이터를 업로드할 수 있습니다.

참고

HTTP를 통한 SOAP 지원은 중단되었지만 HTTPS를 통해 계속해서 사용할 수 있습니다. 새로운 Amazon S3 기능은 SOAP에 대해 지원되지 않습니다. REST API 또는 AWS SDK를 사용하는 것이 좋습니다.

사용자가 브라우저를 사용하여 Amazon S3에 콘텐츠를 업로드하려면 HTML 양식을 사용해야 합니다. HTML 양식은 양식 선언과 양식 필드로 구성됩니다. 양식 선언은 요청에 대한 상위 수준 정보를 포함합니다. 양식 필드는 요청에 대한 세부 정보는 물론 요청 인증에 사용되는 정책을 포함하며 요청이 사용자가 지정하는 조건에 부합한다는 것을 보장합니다.

참고

양식 데이터 및 경계(파일의 내용 제외)는 20KB를 초과할 수 없습니다.

이 단원에서는 HTML 양식을 사용하는 방법을 알아봅니다.

HTML 양식 인코딩

양식과 정책은 UTF-8로 인코딩되어야 합니다. HTML 헤딩에 혹은 요청 헤더로 인코딩을 지정하여 양식에 UTF-8 인코딩을 적용할 수 있습니다.

참고

HTML 양식 선언에서 쿼리 문자열 인증 파라미터는 허용되지 않습니다.

다음은 HTML 헤딩의 UTF-8 인코딩 예제입니다.

Copy
<html> <head> ... <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> ... </head> <body>

다음은 요청 헤더의 UTF-8 인코딩 예제입니다.

Copy
Content-Type: text/html; charset=UTF-8

HTML 양식 선언

양식 선언은 작업, 메서드, 엔클로저 유형 등 3개의 구성 요소를 포함합니다. 이들 값 중 하나라도 잘못 설정되는 경우 요청이 실패합니다.

이 작업은 요청을 처리하는 URL을 지정하는 것이므로 반드시 버킷의 URL로 설정되어야 합니다. 예를 들어 버킷의 이름이 "johnsmith"인 경우 URL은 "http://johnsmith.s3.amazonaws.com/"입니다.

참고

키 이름은 양식 필드에 지정됩니다.

메서드는 POST이어야 합니다.

엔클로저 유형(enctype)은 반드시 지정되어야 하며 파일 업로드와 텍스트 영역 업로드 모두에 대해 multipart/form-data로 설정되어야 합니다. 자세한 내용은 RFC 1867를 참조하십시오.

다음은 버킷 "johnsmith"에 대한 양식 선언 예제입니다.

Copy
<form action="http://johnsmith.s3.amazonaws.com/" method="post" enctype="multipart/form-data">

HTML 양식 필드

다음 표에서는 HTML 양식 내에서 사용할 수 있는 필드를 설명합니다.

참고

변수 ${filename}은 사용자가 제공한 파일의 이름으로 자동 대체되며 모든 양식 필드가 이 변수를 인식합니다. 브라우저나 클라이언트에 파일의 전체 또는 부분 경로가 지정되어 있는 경우 슬래시(/) 또는 백슬래시(\) 뒤에 오는 텍스트만 사용됩니다. 예를 들면, "C:\Program Files\directory1\file.txt"는 "file.txt"로 해석됩니다. 파일이나 파일 이름이 제공되는 경우 변수가 빈 문자열로 대체됩니다.

필드 이름 설명 필수
AWSAccessKeyId

정책에 속하는 일련의 제약 조건을 충족하는 요청에 대해 익명 사용자 액세스를 허용하는 버킷 소유자의 AWS 액세스 키 ID입니다. 요청이 정책 문서를 포함하는 경우 이 필드는 필수입니다.

조건

acl

Amazon S3 ACL(액세스 제어 목록)입니다. 잘못된 액세스 제어 목록이 지정되는 경우 오류가 발생합니다. ACL에 대한 자세한 내용은 액세스 제어 목록을 참조하십시오.

유형: 문자열

기본: 프라이빗

Valid Values: private | public-read | public-read-write | aws-exec-read | authenticated-read | bucket-owner-read | bucket-owner-full-control

아니요

Cache-Control, Content-Type, Content-Disposition, Content-Encoding, Expires

REST 지정 헤더입니다. 자세한 내용은 PUT Object 단원을 참조하십시오.

아니요

key

업로드된 키의 이름입니다.

사용자가 제공한 파일 이름을 사용하려면 ${filename} 변수를 사용하십시오. 예를 들어 사용자 Betty가 파일 lolcatz.jpg을 업로드하고 경로가 /user/betty/${filename}으로 지정돼 있는 경우, 파일은 /user/betty/lolcatz.jpg로 저장됩니다.

자세한 내용은 객체 키와 메타데이터를 참조하십시오.

policy

요청에서 허용되는 항목을 설명하는 보안 정책입니다. 보안 정책이 없는 요청은 익명으로 간주되며 공개적으로 쓰기 가능한 버킷에서만 요청이 허용됩니다.

아니요

success_action_redirect, redirect

업로드 완료 시 클라이언트가 리디렉션되는 URL입니다. Amazon S3은 해당 URL에 버킷, 키 및 etag 값을 쿼리 문자열 파라미터로 추가합니다.

success_action_redirect를 지정하지 않을 경우 Amazon S3은 success_action_status 필드에 지정된 빈 문서 유형을 반환합니다.

Amazon S3이 URL을 해석할 수 없는 경우 해당 필드는 무시됩니다.

업로드가 실패하는 경우 Amazon S3가 오류를 표시하고 사용자는 어떤 URL로도 리디렉션되지 않습니다.

자세한 내용은 리디렉션 단원을 참조하십시오.

참고

리디렉션 필드 이름을 더 이상 사용하지 않는 경우 해당 리디렉션 필드 이름에 대한 지원이 조만간 제거됩니다.

아니요

success_action_status

success_action_redirect를 지정하지 않을 경우 업로드 완료 시 클라이언트에 반환되는 상태 코드입니다.

유효한 값은 200, 201 또는 204입니다(기본값).

200 또는 204로 값을 설정하는 경우 Amazon S3은 상태 코드가 200 또는 204인 빈 문서를 반환합니다.

201로 값을 설정하는 경우 Amazon S3은 상태 코드가 201인 XML 문서를 반환합니다. XML 문서의 내용에 대한 자세한 내용은 POST Object 단원을 참조하십시오.

값이 설정되지 않거나 유효한 값으로 설정되지 않는 경우 Amazon S3은 상태 코드가 200 또는 204인 빈 문서를 반환합니다.

참고

일부 버전의 Adobe Flash Player는 본문이 비어 있는 HTTP 응답을 올바르게 처리하지 못합니다. Adobe Flash를 통한 업로드를 지원하려면 success_action_status를 201로 설정하는 것이 바람직합니다.

아니요

signature

제공된 AWSAccessKeyId에 해당하는 보안 액세스 키를 사용하여 생성하는 HMAC 서명입니다. 요청과 함께 정책 문서가 포함되는 경우 이 필드는 필수입니다.

자세한 내용은 Using Auth Access 단원을 참조하십시오.

조건

x-amz-security-token

Amazon DevPay 및 세션 자격 증명이 사용하는 보안 토큰

요청이 Amazon DevPay를 사용하는 경우 제품 토큰과 사용자 토큰에 하나씩 2개의 x-amz-security-token 양식 필드가 요청에 필요합니다. 자세한 내용은 Using DevPay 단원을 참조하십시오.

요청이 세션 자격 증명을 사용 중인 경우 이 요청에는 x-amz-security-token 양식이 필요합니다. 자세한 내용은 IAM 사용 설명서임시 보안 자격 증명 단원을 참조하십시오.

아니요

x-amz-meta- 접두사가 붙는 기타 필드 이름

사용자 지정 메타데이터입니다.

Amazon S3은 이 데이터를 확인하거나 사용하지 않습니다.

자세한 내용은 PUT Object 단원을 참조하십시오.

아니요

파일

파일 또는 텍스트 콘텐츠입니다.

파일이나 콘텐츠는 양식의 마지막 필드이어야 합니다. 그 다음 필드는 모두 무시됩니다.

한 번에 파일 하나만 업로드할 수 있습니다.

정책 구성

정책은 요청이 충족해야 하는 조건을 지정하고 콘텐츠를 인증하는 데 사용되는 UTF-8 및 Base64로 인코딩된 JSON 문서입니다. 정책 문서를 디자인하는 방법에 따라 모든 업로드에 대하여 업로드 단위나 사용자 단위로 혹은 필요에 맞는 다른 디자인에 따라 문서를 사용할 수 있습니다.

참고

정책 문서가 선택 사항이긴 하지만, 버킷을 공개적으로 읽기 가능하도록 설정하는 것보다는 정책 문서를 적극 권장합니다.

다음은 정책 문서의 예입니다.

Copy
{ "expiration": "2007-12-01T12:00:00.000Z", "conditions": [ {"acl": "public-read" }, {"bucket": "johnsmith" }, ["starts-with", "$key", "user/eric/"], ] }

정책 문서는 만료 및 조건을 포함합니다.

만료

만료 요소는 ISO 8601 UTC 데이터 형식으로 된 정책의 만료 날짜를 지정합니다. 예를 들어 "2007-12-01T12:00:00.000Z"는 해당 정책이 2007년 12월 1일 자정(UTC)이 지나면 유효하지 않다는 것을 명시합니다. 만료는 정책에 필수 사항입니다.

조건

정책 문서에 포함되는 조건은 업로드된 객체의 내용에 대한 유효성 검증에 사용됩니다. 양식에 지정하는 각 양식 필드(x-ignore- 접두사가 오는 AWSAccessKeyId, 서명, 파일, 정책 및 필드 이름 제외)는 조건 목록에 포함돼야 합니다.

참고

이름이 같은 필드가 여러 개 있는 경우 해당 값을 쉼표로 구분해야 합니다. 예를 들어 "x-amz-meta-tag"라 명명된 필드가 2개이고 첫 번째 필드 값이 "Ninja", 두 번째 필드 값이 "Stallman"이라면 정책 이름을 Ninja,Stallman이라 설정할 것입니다.

이 양식에 들어 있는 모든 변수가 확장돼야 정책의 유효성이 검증됩니다. 따라서 이렇게 확장된 필드에 대하여 모든 조건을 대조해야 합니다. 예를 들어 키 필드를 user/betty/${filename}으로 설정했다면 [ "starts-with", "$key", "user/betty/" ]와 같은 정책을 사용할 수 있습니다. [ "starts-with", "$key", "user/betty/${filename}" ]는 입력할 수 없습니다. 자세한 내용은 조건 매칭을 참조하십시오.

다음 표에서는 정책 문서 조건을 설명합니다.

요소 이름 설명
acl

ACL이 충족해야 하는 조건을 지정합니다.

하드 매칭 및 starts-with를 지원합니다.

content-length-range

업로드되는 콘텐츠에 대하여 허용 가능한 최소 및 최대 크기를 지정합니다.

범위 매칭을 지원합니다.

Cache-Control, Content-Type, Content-Disposition, Content-Encoding, Expires

REST 지정 헤더입니다.

하드 매칭 및 starts-with를 지원합니다.

업로드된 키의 이름입니다.

하드 매칭 및 starts-with를 지원합니다.

success_action_redirect, redirect

업로드 완료 시 클라이언트가 리디렉션되는 URL입니다.

하드 매칭 및 starts-with를 지원합니다.

success_action_status

success_action_redirect를 지정하지 않을 경우 업로드 완료 시 클라이언트에 반환되는 상태 코드입니다.

하드 매칭을 지원합니다.

x-amz-security-token

Amazon DevPay 보안 토큰입니다.

Amazon DevPay를 사용하는 각 요청에는 제품 토큰과 사용자 토큰에 하나씩 하여 2개의 x-amz-security-token 양식 필드가 필요합니다. 따라서 해당 값을 쉼표로 구분해야 합니다. 예를 들어 사용자 토큰이 eW91dHViZQ==이고 제품 토큰이 b0hnNVNKWVJIQTA=인 경우 정책 항목을 { "x-amz-security-token": "eW91dHViZQ==,b0hnNVNKWVJIQTA=" }로 설정합니다.

Amazon DevPay에 대한 자세한 내용은 Using DevPay 단원을 참조하십시오.

x-amz-meta- 접두사가 붙는 기타 필드 이름

사용자 지정 메타데이터입니다.

하드 매칭 및 starts-with를 지원합니다.

참고

도구 키트로 필드를 추가하는 경우(예: Flash에 의한 파일 이름 추가 등) 정책 문서에 해당 필드를 추가해야 합니다. 이 기능을 제어할 수 있는 경우 해당 필드에 x-ignore- 접두사를 붙여야 Amazon S3이 해당 기능을 무시하고 나중 버전의 기능에 영향을 주지 않습니다.

조건 매칭

다음 표에서는 조건 매칭 유형을 설명합니다. 양식에 지정하는 양식 필드마다 조건을 하나씩 지정해야 하지만 양식 필드 하나에 여러 조건을 지정하면 좀 더 복잡한 매칭 조건을 만들 수 있습니다.

Condition 설명

완전 매치

완전 매치로 필드가 특정 값과 일치하는지 확인합니다. 이 예제는 ACL이 public-read로 설정돼야 한다는 것을 나타냅니다.

Copy
{"acl": "public-read" }

이 예제를 통해 ACL이 public-read로 설정되어야 함을 알 수 있습니다.

Copy
[ "eq", "$acl", "public-read" ]

Starts With(다음으로 시작)

값이 특정 값으로 시작돼야 하는 경우 starts-with를 사용합니다. 이 예제는 키가 user/betty로 시작돼야 한다는 것을 나타냅니다.

Copy
["starts-with", "$key", "user/betty/"]

내용 무관 매칭

필드에 들어 있는 모든 내용을 허용하도록 구성하려면 값이 비어 있는 starts-with를 사용합니다. 이 예제에서는 어떤 success_action_redirect도 허용됩니다.

Copy
["starts-with", "$success_action_redirect", ""]

범위 지정

범위를 허용하는 필드의 경우 상위 및 하위 범위를 쉼표로 구분하십시오. 이 예제에서는 1~10MB의 파일 크기가 허용됩니다.

Copy
["content-length-range", 1048579, 10485760]

문자 이스케이프

다음 표에서는 정책 문서 내에서 이스케이프되어야 하는 문자들을 설명합니다.

이스케이프 시퀀스 설명

\\

백슬래시

\$

달러 기호

\b

백스페이스

\f

용지 공급

\n

줄 바꿈

\r

캐리지 리턴

\t

가로 탭

\v

세로 탭

\uxxxx

모든 유니코드 문자

서명 생성

단계 설명
1

UTF-8을 이용하여 정책을 인코딩합니다.

2

Base64를 사용하여 해당 UTF-8을 인코딩합니다.

3

HMAC SHA-1을 사용하여 보안 액세스 키가 있는 정책에 서명합니다.

4

Base64를 사용하여 SHA-1 서명을 인코딩합니다.

인증에 대한 일반적인 정보는 Using Auth Access 단원을 참조하십시오.

리디렉션

이 단원에서는 리디렉션 처리 방법을 설명합니다.

일반 리디렉션

POST 요청이 완료되면 사용자가 success_action_redirect 필드에 직접 지정한 위치로 리디렉션됩니다. Amazon S3이 URL을 해석할 수 없는 경우 success_action_redirect 필드는 무시됩니다.

success_action_redirect를 지정하지 않을 경우 Amazon S3은 success_action_status 필드에 지정된 빈 문서 유형을 반환합니다.

POST 요청이 실패하는 경우 Amazon S3이 오류를 표시하고 리디렉션을 제공하지 않습니다.

서전 업로드 리디렉션

<CreateBucketConfiguration>을 사용하여 버킷을 만든 경우 최종 사용자의 경우 리디렉션이 필요할 수 있습니다. 이렇게 되는 경우 일부 브라우저에서 리디렉션이 잘못 처리될 수도 있습니다. 이러한 경우는 비교적 드물게 일어나지만 버킷을 만든 직후 발생할 가능성이 가장 높습니다.