multipart/form-data

요 전날 Java HttpURLConnection을 사용하여 통신 처리를 구현했습니다.
그 중에서 multipart/form-data 형식으로 범용적으로 전송할 수 있는 부품을 만들고 있었습니다만, 왠지 몇번 통신해도 multipart/form-data의 리퀘스트로서 인식되지 않고, 해결에 상당한 시간을 지출했습니다.

원인은 매우 어려운 내용으로, 이런 일로 빠지는 녀석이 다른 것인가? 라는 느낌이었습니다만, 비망록적인 의미도 겸해 써 두고 싶습니다.

덧붙여서 처음으로 써 버리자, 원인은 이 녀석이었습니다.

multipart/form-data의 요청 본문

일반적인 것은 이런 느낌입니다.
아래와 같은 형식으로 조립한 내용을 Body에 실어 통신합니다.

multipart/form-data 몸

--[Boundary文字列]
Content-Disposition: form-data; name="[フォーム名]"

<<フォームの内容>>
--[Boundary文字列]
Content-Disposition: form-data; name="[フォーム名]"; filename="[ファイル名]"
Content-Type: text/plain

<<ファイルの内容>>
--[Boundary文字列]
・
・
・
送る分だけ続く
・
・
・
--[Boundary文字列]--

요청 헤더의 Content-Type은 multipart/form-data, Boundary 문자열은 Content-Type 뒤에 써 둡시다.
개행 코드는 반드시 CRLF로.

어째서인지 인식되지 않는다・・・

송신한 리퀘스트의 리퀘스트 바디를 보는 것도, 상기의 형식과 비교해 확실히 잘못되어 있는 기색이 없고, 리퀘스트 헤더의 Content-Type의 Boundary 지정도 틀림없다.
음?

원인

Postman에서 formdata 형식으로 통신하고 성공적으로 인식 된 요청과 비교하면,

multipart/form-data 몸

--[Boundary文字列]

의 첫 번째 "--"가 없었습니다. .
처음에는, 너무 multipart/form-data의 구조에 자세하지 않고, 넷상의 사이트를 참고로 만들고 있었습니다만, 여러가지 사이트에서 Boundary 문자열로서 「-------- 랜덤인 문자열」 같은 지정이었으므로, 거기에 배워 처음에 「--------」를 붙인 문자열을 지정하고 있어, 최초로 별도 「--」가 필요하다고 하는 인식이 부족한 일 라고, 실제로 빠지고 있는지의 확인이 해 괴로웠던 것이 원인이었습니다. (RFC 제대로 읽을 수 있다고 하는 이야기입니다만.)

덧붙여서 마지막 구분은 뒤에도 「--」가 필요하다 조! (심심)

교훈

추억은 무섭다.

같은 내용으로 막히는 사람이 나오지 않도록 써 둡니다. (그런 사람 없나)

이어서

덧붙여서, HTTP 통신 테스트를 할 때는 다음 사이트를 추천합니다.
GET이나 POST로 보낸 요청의 정보 등을 JSON의 형태로 돌려주는 엔드포인트나 바이너리의 응답을 돌려주거나, 그 밖에도 다양한 엔드포인트가 준비되어 있기 때문에 간단한 통신 내용의 확인으로부터 상당히 확실한 통신의 테스트도 실시할 수 있습니다.

아시는 분이 있으면 꼭 이용해 보세요. 드리겠습니다.
httpBin : h tps // h tp 병. rg/