[422에러] content-type

출처 : https://www.rfc-editor.org/rfc/rfc4918#section-11.2

RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)

The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

어제 만났던 422에러에 대해서 찾아본 결과다. 

 

"422(처리할 수 없는 엔터티) 상태 코드는 서버가 요청한 엔터티를 이해하고(그러나 415 상태 코드(지원되지 않는 미디어타입)는 적합하지 않음) 그리고 요청 엔터티의 문법은 정확하다(그러나 400(잘못된 요청) 상테 코드는 적합하지 않음) 그러나 포함된 명령을 처리할 수 없었다는 의미다. 

예를들어 이 에러 상태는 만약 XML 요청의 바디의 형식은 올바르지만(즉, 구문상 올바름) 의미적으로 잘못된, XML 명령을 포함했을 때 발생 할 수 있다"

 

 

즉, 내가 요청한 엔터티는 서버가 이해를 했고 문법은 정확하나 포함된 명령을 처리할 수 없다는 말.. 

내가 해결한 것은 content-type을 헤더에 포함함으로써 해결되었는데 그 방식이 이 상황과 부합한다..

 

 

▶ 의문점 : content-type을 반드시 포함해야 할까?

udemy의 react 완벽가이드 강의 강사가 content-type은 필수적이지는 않지만 

명확히 하기 위해 넣어야 한다는 이야기를 들었던 것 같다. 

 

그래서 구글링 해보니 stack overflow 에서 나와같은 질문을 했던 사람이 있었다. 

 

Is Content-Type mandatory in HTTP post request?

출처:https://stackoverflow.com/questions/15860742/is-content-type-mandatory-in-http-post-request

Is Content-Type mandatory in HTTP post request?

 

 

 

 

그 답변에는 w3school의 내용을 참조로 하여 필수는 아니라는 답변이 있었다. 

 

Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".

 "엔터티 바디를 포함하고 있는 HTTP1.1 메시지는 그 바디의 미디어 타입을 정의하는 content-type 헤더 필드를 포함하여야 한다. 

컨텐트 타입 필드에서 미디어타입이 주어지지 않는 경우 수신자는 컨텐트 그리고/또는 리소스를 식별하는데 사용되는 URI의 이름 확장명 검사를 통해 미디어 타입을 추측하려고 시도할 것이다. 만약 미디어타입을 알 수 없는경우, 수신자는 타입을 "application/octet-stream"으로 취급해야 한다. "

 

그러므로 수신자에게 해당 미디어타입을 정확히 추측하게 해주려면 content-type을 포함하는 것이 좋다는 것으로 정리하면 될 것 같다. 

 

 

 

 

 

▶ 출처에 대한 공부 : 

가장 힘들었던 것 중의 하나가 레퍼런스에 대한 분별이었다. 

모든 학문에는 레퍼런스가 있는데,

한국어로 번역된 책을 찾자니 너무 학문이 방대해지는 것을 느낀다. 

잘 정리되어있는 책도 물론 많지만

아무래도 접근성 방면에서 계속 구글링 하게 되는 것은 어쩔 수 없는 것 같다.

 

블로그는 물론 훌륭한 분들이 작성하였고 잘 정리되어있는 것도 많았지만 

나같은 초보들도 블로그를 작성할 수 있기에 무언가 

인터넷으로 접근할 수 있는, 신뢰할 만한 레퍼런스를 찾는것이 시급했다. 

 

많은 선배들의 조언을 살펴보면 레퍼런스를 읽는 것이 중요하다고 되어있었고 

stack overflow도 너무 믿지 말라는 말도 덧붙여 있었다.

 

rfc-editor 사이트 : 

참고 : 위키백과  (https://en.wikipedia.org/wiki/Request_for_Comments)

Request for Comments - Wikipedia

A Request for Comments(RFC) is a publication in a series from the principal tec뚜hnical development and standards-setting bodies for the Internet, most prominently the Internet Engineering Task Force  (IETF). An RFC is authored by individuals or groups of engineers and computer scientists in the form of a memorandum
 describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems. It is submitted either for peer review or to convey new concepts, information, or, occasionally, engineering humor

 

RFC(Request for Comments)는 인터넷의 주요 기술 개발 및 표준 설정 기관, 특히 IETF(Internet Engineering Task Force)에서 발행한 시리즈 간행물입니다. RFC는 각서의 형태로 개인 또는 엔지니어 및 컴퓨터 과학자 그룹에 의해 작성됩니다. 인터넷 및 인터넷 연결 시스템의 작업에 적용할 수 있는 방법, 동작, 연구 또는 혁신을 설명합니다. 동료 검토를 위해 또는 새로운 개념, 정보 또는 경우에 따라 엔지니어링 유머를 전달하기 위해 제출됩니다. -구글번역

 

 

https://net-study.club/entry/RFC-Request-for-Comments-%EB%AC%B8%EC%84%9C-%EC%97%B4%EB%9E%8C-%EC%82%AC%EC%9D%B4%ED%8A%B8-RFC-Editor-IETF%C2%AE-Datatracker

 

RFC (Request for Comments) 문서 열람 사이트 - RFC Editor, IETF® Datatracker

 

 

w3schools.com : 

W3스쿨즈(w3schools.com)는 온라인으로 웹 기술을 배우는 교육용 웹 사이트이다.
콘텐츠에는 HTML, CSS 자바스크립트, JSON, PHP, 파이썬, XML, SQL, Bootstrap, Node.js, JQuery등 다양한 교육용 자료를 제공한다. W3스쿨즈의 강력한 점은 직관적이고 일반적인 실행 및 소스의 실시간 듀얼 화면을 제공한다는 점이다. Tryit 편집기 및 샌드박스로도 잘 알려진 이것은 사용자에게 소스코드가 어떻게 실행 결과로 나타나는지를 즉시 확인할 수 있게 해준다.
1998년에 만들어진 이 단체의 이름은 월드 와이드 웹인 W3C에서 유래되었지만 W3C(World Wide Web Consortium)와는 관련이 없다. 노르웨이의 Refsnes Data에 의해 운영되고 있다.[4]W3School은 수천 개의 코드 예를 제시한다. TryIt 편집기를 사용하여, 사용자는 샘플 소스의 예를 직접 편집하고 샌드박스에서 코드를 실행하고 결과를 즉시 확인할 수 있는데 이러한 샌드박스 실행은 서버와 클라이언트와의 상호작용을 깊이있게 이해하는데 좋은 교육방식의 하나이다.