Constrained Things

서버에서 atomic 방식의 블록형 요청 페이로드(예: PUT/POST) 를 수신하는 경우, 최종 블록, 즉 M 비트가 0 인 Block1 옵션을 포함한 블록이 수신되었을 때 실제 작성/대체가 이루어집니다. 이 경우, 최종 블록이 아닌 모든 성공 응답은 응답 코드 2.31 (Continue)을 반환합니다. 마지막 블록을 처리 할 때, 서버에서 모든 이전 블록들이 가용하지 않다면, 전송은 실패하며 오류 코드 4.08 (Entity Incomplete Request)이 반드시 반환되어야 합니다. 서버는 비순차적인 임의의 (최종 또는 비 최종) Block1 전송에 대해 4.08 오류 코드를 반환할 수도 있습니다. 따라서, 이 경우를 처리할 특정 메커니즘이 없는 클라이언트는 항상 블록 0 을 시작으로 블록들을 순서대로 전송해야 합니다.

클라이언트가 4.08 오류 코드를 수신하는 이유중 하나는, 서버에서 시간이 초과되어 부분 요청 내용을 폐기했기 때문입니다. 클라이언트는 과도한 지연없이 요청을 구성하는 모든 블록을 보내려고 노력해야 합니다. 서버는 가장 최근 블록이 전송 된 후 EXCHANGE_LIFETIME 이 경과하면 부분 요청 본문을 마음껏 버릴 수 있습니다. 그러나 서버에서 항상 부분 요청 본문을 오래 보관할 필요는 없습니다.

atomic 방식의 블록형 요청 페이로드 전송에서, 서버는 블록 저장에 필요한 자원이 없는 경우 오류 코드 4.13 (요청 엔티티가 너무 큼) 을 언제든지 반환 할 수 있습니다. (Block1 을 사용하지 않는 요청에 대한 4.13 응답은 클라이언트에게 Block1 로 전송해보라고 하는 힌트이며, 요청한 SZX 보다 더 작은 SZX이 들어있는 Block1 옵션이 포함된 4.13 응답은 더 작은 SZX 로 요청해 달라는 힌트임을 유의하십시오.)

stateless 방식의 블록형 요청 페이로드 전송에서, 서버는 전송이 진행중이거나 클라이언트로부터 전송이 완료되지 않은 동안 비일관적 상태에서 운영될 수 있습니다.  이 특성은 전송 중 서버에 state 가 항상 유지되는 HTTP 보다는 원격 파일 시스템의 특성에 더 가깝습니다. 공유 파일 액세스 (예: 클라이언트 특정 임시 리소스)에서 잘 알려진 기술을 사용하여 HTTP 와의 차이를 완화 할 수 있습니다.

Block1 옵션은 단일 종단점이 동일한 자원에 대해 동시에 여러 개의 블록 방식 요청 페이로드 전송 (예 : PUT 또는 POST) 작업을 수행 할 수있는 방법을 제공하지 않습니다. 동일한 종단점의 이전 시퀀스가 완료되기 전에 동일한 자원에 대한 새로운 블록 단위의 요청을 시작하면 서버가 계속 유지할 수있는 컨텍스트를 단순히 덮어 씁니다.