Requests: 파일 없이 멀티파트 게시물 생성

이것은 이전에 논의되었습니다. @kennethreitz 가

개인적으로 API의 사전(튜플 목록 등)에서 멀티파트 데이터를 생성하는 함수를 노출하여 사용자가 이를 사용하고 생성된 데이터를 요청에 전달할 수 있도록 하는 것이 더 좋습니다. 표면적으로, 그들이 파일을 사용하지 않는다면, 엄청난 메모리 히트가 없어야 하지만, 그럼에도 불구하고 그들은 이미 메모리에 하나의 거대한 문자열을 가지고 있고, 두 번째는 실제로 그들을 죽이지 않을 것이고 그것은 우리가 아닌 그들의 잘못일 것입니다. .

아마도 @kennethreitz 는 두 번째 솔루션에 더

실제로 현재 API는 파일 이외의 멀티파트 데이터 전송을 지원하지 않으며 이것은 나쁜 것입니다. 문제 #935 및 shazow/urllib3/issues/120 참조

어쩌면 내가 뭔가를 놓치고 있을지도 모르지만 그 변화는 나에게 다소 사소한 것처럼 보입니다. 저장소를 분기하고 내 버전에 제안된 변경 사항이 있습니다. https://github.com/spacecase/requests/commit/45b0b3ce1e76b241b323570a5fc88ae2089c3c3d
(이 작업을 수행하는 더 좋은 방법이 있다면 알려주십시오. 저는 github에 익숙하지 않습니다.)

몇 개의 단위 테스트가 필요할 수도 있고 api.py의 독스트링을 변경해야 할 수도 있지만 이와 같은 것이 합리적입니까?

변경 사항의 문제는 구현이 복잡하다는 것이 아니라 API의 차이입니다. 저는 이 진행 중인 토론에서 일종의 경계에 서 있습니다. 여러 부분으로 구성된 양식 데이터를 업로드하는 좋은 방법이 있으면 유용할 것이라고 생각하지만 현재의 files API도 매우 좋은 방법이라고 생각합니다. . 나는 Request API에 multipart 를 추가하는 것이 갈 길이라고 생각하지 _않습니다_.

솔직히 저는 개인적으로 콘텐츠 유형 헤더를 통해 제어하고 싶지만 현재 우리가 하는 것보다 100배 더 오류가 발생하기 쉽고 새로운 사용자에게 혼란을 줄 것입니다. 나는 이것에 대해 울타리에 있지만 여전히 이것을하지 않는 측면에서 실수를 할 것입니다.

왜요? 이 기능 요청을 수락하면 누군가 json 매개변수가 없다고 불평할 가능성이 높아집니다. 그리고 다른 사람들이 추가되었으면 하는 더 많은 매개변수를 생각해낼 수 있을 것이라고 확신합니다. 현재와 ​​같이 API는 해야 할 일을 정확히 수행하며 크러프트가 거의 또는 전혀 없습니다. 이것을 보는 한 가지 방법은 KISS입니다. 이것은 요청을 만들고 응답을 쉽고 자연스럽게 만드는 훌륭한 객체를 반환합니다. 광고된 대로 수행하고 나머지는 사용자가 수행합니다. 멀티파트 인코딩을 광고하고 문서화된 디자인을 통해 수행합니다. 어색해 보일 수 있지만 문서화되어 작동합니다.

_(...) 누군가는 json 매개변수가 없다고 불평할 것입니다_

json이 multipart 미디어 유형( httpbis draft 21 )이 아닌 multipart application 미디어 유형( rfc4627 )의 하위 유형이기 때문에 그러한 불평에 대한 근거는 없습니다.

_어려워 보일 수 있습니다(...)_

어색한 반면에 있어서는 안 됩니다.

이전 의견을 읽은 후 내 입장을 반복하고 싶습니다. multipart/form-data 는 현재 사용되는 가장 일반적인 다중 부분 MIME 유형이며(인용 필요 :)) 이를 지원하지 않는 것은 큰 생략입니다.

@piotr-dobrogost: 위에서 말한 것에도 불구하고, 나는 당신이 약간 설득력 있게 주장한 주장을 찾지 못했습니다.

요청은 MIME 유형을 지원하지 않으며 사용 사례를 지원합니다. 이 관점은 위의 두 의견을 이상하게 만듭니다. 예를 들어 JSON 매개변수가 없는 것에 대한 불만은 JSON 형식의 데이터를 업로드하는 것이 매우 일반적이기 때문입니다. 아마도 파일이 아닌 멀티파트 데이터를 업로드하는 것보다 요청 사용자에게 더 일반적일 것입니다. '우리는 multipart 의 특수한 경우의 하위 유형만 '하기 때문에 제공하지 않을 것이라고 주장하는 것은 이상한 말처럼 보입니다.

그럼에도 불구하고 문제의 핵심은 다음과 같습니다. API는 이 라이브러리의 요점입니다. 이 기능을 구현하는 _아름다운_ 방법을 생각해내지 못한다면 그런 일은 일어나지 않을 것입니다.

그런 불평에 대한 근거가 없을 것입니다 [원문 그대로]

@piotr-dobrogost 당신은 나보다 개발자의 미래에 대해 더 많은 희망을 가지고 있습니다. 그 외에는 요청한 매개변수가 정확하지 않습니다. form_data 보다 multipart form_data 와 같은 이름으로 호출해야 합니다. 아시다시피 (간접적이지만) multipart 는 다양한 미디어 유형을 참조할 수 있습니다.

어색한 반면에 있어서는 안 됩니다.

모든 것이 우아할 수는 없습니다(파이썬에서도).

그리고 그것을 지지하지 않는다.

하지만 지원됩니다. 그러나 그 외에, 우리가 data 에 대해 application/x-www-form-urlencoded , files (또는 files+data )에 대한 multipart/form-data , 왜 우리는 또 다른 매개 변수를 필요로 하는가 우리가 그것을 가지고 있을 때 단지 multipart/form-data 를 위해?

원하는 결과를 얻기 위해 data 및 files 조합을 사용할 필요가 없습니다. 실제 파일 없이 requests.post('http://example.com/', files=[('key1', 'param1'), ('key2', 'param2')]) 와 유사한 작업을 수행할 수 있습니다.

그리고 정확히 말하면 form_data 가 완전히 명확하지 않을 수 있으므로 multipart_form_data 매개변수를 사용하지 않는 이유는 무엇입니까? 그것은 명시적입니다. 예, PEP 8은 명시적으로 요구하지만 기존 동작은 잘 문서화되어 있습니다. @kennethreitz 가 이 기능 요청을 수락하기로 결정한 경우 모든 매개변수는 파일 매개변수에 대한 별칭으로 작동해야 합니다. 그러나 동작이 이미 지원되는 것을 고려하면 필요하지 않다고 생각합니다.

@sigmavirus24 와 @Lukasa는 이것을 완벽하게 요약했습니다.

@piotr-dobrogost 귀하의 기여는 높이 평가되지만 귀하의 어조는 아닙니다. 우리 프로젝트와 목표에 대해 확고한 주장을 하는 것을 중단하십시오.

내 관점에서는 요청이 이미 여러 부분으로 구성된 게시물을 지원하지만 파일을 사용하지 않고는 사용자에게 액세스 권한을 제공하지 않는다는 사실이 상당히 실망스럽습니다. @sigmavirus24 의 파일을 거기에

나는 이것이 앞으로도 사용자들에게 계속해서 문제가 될 것이라고 생각하는데, 왜 이것을 해결하려는 노력이 없는 것 같아 조금 혼란스럽습니다.

#935에 대한 내 응답 보기

오 감사. 기대됩니다!

@루카사

_Requests는 MIME 유형을 지원하지 않으며 사용 사례를 지원합니다._

multipart/form-data 데이터를 보내는 것은 일반적인 사용 사례입니다.

_(...) JSON 형식의 데이터를 업로드하는 것은 매우 일반적입니다(...)_

json을 보내는 것과 multipart/form-data 를 보내는 것을 비교할 수 없습니다. json을 보내는 것은 쉽습니다. Content-type 설정하고 내장 모듈을 사용하여 데이터를 한 줄로 인코딩하면 됩니다. multipart/form-data 보내는 것은 요청의 본문이 특정 구조를 가져야 하기 때문에 더 복잡합니다. 즉, json을 보내는 것은 HTTP에 관한 한 투명하지만 multipart/form-data 보내는 것은 그렇지 않습니다. Requests는 HTTP 라이브러리이므로 그러한 구조를 생성하는 데 주의해야 합니다.

_이 기능을 구현하는 아름다운 방법을 생각해내지 못하면 일어나지 않을 것입니다._

파일과 아무 관련이 없는 multipart/form-data 를 보내기 위해 현재 files 매개변수를 갖는 것은 어떤 식으로든 아름답지 않지만(추악합니다), 어떻게든 코드베이스에 들어갈 수 있었습니다. :). 덜 추한 것을 생각해내는 것은 정말 쉽습니다 :)

@sigmavirus24

_(...) 그러나 기존 동작은 잘 문서화되어 있습니다._

아무리 많은 문서도 나쁜 API에서 좋은 API를 만들지 않습니다. API가 좋을수록 문서가 덜 필요합니다.

_(...)_와 유사한 작업을 할 수 있습니다.

맞습니다. 하지만 이것은 매우 오해의 소지가 있고 직관적이지 않습니다. 이전 댓글에서 files param을 사용하는 것이 잘못된 점을 설명했습니다.

결론: 더 나은 것을 생각해내려면 현재 API가 multipart/form-data 데이터를 보내는 것과 관련하여 나쁘다는 것을 인정해야 합니다.

@스페이스케이스

_내 관점에서는 요청이 이미 여러 부분으로 구성된 게시물을 지원하지만 파일을 사용하지 않고는 사용자에게 액세스 권한을 제공하지 않는다는 사실이 상당히 실망스럽습니다._

동의하며 이것이 문제 #935를 만든 이유입니다.

이 문제는 종료되었습니다.

@kennethreitz를 용서하세요 @spacecase 저는 이 예제에서 파일을 사용하지 않았습니다. 나는 당신이 원하는 것을 정확히 하기 위해 파일 매개변수를 사용했습니다. 파일을 사용했다면 open('filename') 보았을 것입니다.

@sigmavirus24 , 불행히도 그것은 내가 원하는 것이 아닙니다. 클라이언트가 파일에서 읽고 있는지 여부는 중요하지 않습니다. 서버에 알려주는 내용입니다. 귀하의 예에서 게시물 본문은

Content-Disposition: form-data; name="key1"; filename="key1"
Content-Type: application/octet-stream

param1
--2f8732ee35564115a6c6e0c1032773e8
Content-Disposition: form-data; name="key2"; filename="key2"
Content-Type: application/octet-stream

param2
--2f8732ee35564115a6c6e0c1032773e8--

filename= 의 사용에 주의하십시오. 서버에 파일이 전송되고 있음을 알려줍니다. 웹 앱에서 이 잘못된 동작으로 작업하면 오류가 발생합니다.

미안하지만, 내가 원하는 것이 바로 그것이라고 말하는 당신이 너무 주제넘게 말하는 것은 나를 화나게 합니다. 나는 아이디어와 도움을 제공하기 위해 왔습니다. 그리고 당신은 이 경우 둘 다 원하지 않는 것 같습니다. 괜찮습니다만, 저를 얕잡아보게 하지 말아주세요.

흠, 행동을 잘못 기억한 것 같습니다. 미안합니다. 당신을 화나게 하거나 말을 거는 기분이 들게 하려는 의도는 전혀 없었습니다. multipart/form-data 를 처리하는 더 나은 방법이 필요하다는 점에 동의하지만 API에 대한 아이디어가 전혀 우아하지 않다는 점에는 여전히 동의하지 않습니다.

@spacecase #935에 대한 제 답변을 참조하세요. 상황이 나아질 것입니다. 귀하의 피드백은 중요하고 대단히 감사합니다. :)

@spacecase 는 귀하의 의견이 중요하다는 것을 보여주는 제스처로, Content-Type 헤더를 설정해야 하지만 이는 약간의 성가심일 수 있습니다.

@sigmavirus24 감사합니다. 시도해보겠습니다. 트릭을 할 것 같습니다.
당신이 나를 화나게 할 의도가 아니었다는 점에 감사드립니다. 나는 그것에 대해 기분이 좋아지고 당신이나 프로젝트에 대해 아무 것도 가지고 있지 않습니다.

네, 제가 어떤 사람들에게는 뻔뻔하게 들리는 것 같아서 인터넷에 쓰는 것을 다듬어야 할 것 같아요. 나는 그것을 이해하지 못하고 다른 사람들도 나와 동의했지만 나는 그것에 대해 노력하고 있습니다. 나는 내 의도 없이 사람들에게 불쾌감을 주는 것이 무엇인지 깨닫기에 충분히 큰 표본 크기가 필요하다고 생각합니다.

게시할 파일과 몇 가지 키-값이 있습니다. 그렇다면 이러한 mutilpart-form 요청을 보내는 올바른 방법은 무엇입니까? 당신이 나를 도울 수 있기를 바랍니다.

Content-Disposition: form-data; name="up"; filename="aa.PNG"
Content-Type: image/png

file data
---------------------------7dee5302248e
Content-Disposition: form-data; name="exp"


-----------------------------7dee5302248e
Content-Disposition: form-data; name="ptext"

text
-----------------------------7dee5302248e
Content-Disposition: form-data; name="board"

DV_Studio
-----------------------------7dee5302248e--

I tried this way but only got a 504 error.
myfile=[('file',open('bb.jpg')),('exp','python'),('ptext',''),('board','DV_Studio')]
r = requests.post(url,files=myfile)

@deerstalker에 대한 질문은 StackOverflow 를 사용하세요. 귀하의 질문에 답하기 위해 이 문제를 해결하기 위한 프로젝트가 진행 중입니다. sigmavirus24/requests-toolbelt

또한 여기에서 볼 수 있듯이 이전에 StackOverflow에서 이 질문에 답변한 적이

파일 없이 멀티파트 게시물을 생성하는 것과 동일한 문제가 있습니다. 현재로서는 requests.post(url, data=data_dict) 또는 requests.post(url, data=data_dict, files={}) 를 수행해도 차이가 없습니다. 그러나 files 키워드의 기본값은 None 이므로 두 가지 고유한 동작을 가질 수 있어야 합니다. multipart/form-data files={} 지정되며, application/x-www-form-urlencoded 하지 않을 때.

내가 뭐 놓친 거 없니?

@jwoillez 제가 게시한 스택 오버플로 링크를 팔로우하셨나요?

나는 그렇게 생각하지만 거기에 대한 귀하의 답변은 하나의 파일로 Multipart POST를 다룹니다. 원래 문제인 Multipart POST with no file로 돌아갔습니다.

파일 객체는 문자열이 될 수 있습니다. =) 원하는 정보를 제공해야 합니다.

그러나 내가 당신의 제안을 따른다면 나는 다음과 같은 결과를 낳지 않을까요?

Content-Disposition: form-data; name="file"; filename="filename.txt"
Content-Type: text/plain

content
--3eeaadbfda0441b8be821bbed2962e4d--

여기서 content 는 파일 대신 사용하도록 초대한 문자열입니까?

나는 정말로 이것만 쫓고 있다:

Content-Disposition: form-data; name="key1"

value1
--3eeaadbfda0441b8be821bbed2962e4d

원하지 않는 튜플의 필드는 기본값으로 남겨둘 수 있습니다.

files = {'name': ('', 'content')}

앞으로는 StackOverflow로 질문을 보내주세요. 모든 유지 관리자는 정기적으로 이를 추적하며 이러한 질문을 하기에 더 적절한 곳입니다.

찾던 답변이네요 감사합니다. 소음 죄송합니다.

마지막 질문은 다음과 같습니다(빈 파일 이름, 빈 콘텐츠 지정)?

Content-Disposition: form-data; name="file"; filename=""
Content-Type: text/plain


--3eeaadbfda0441b8be821bbed2962e4d--

튜플의 콘텐츠 섹션에 빈 문자열을 사용하여 빈 콘텐츠를 제공할 수 있습니다. 문자 그대로 빈 파일 이름을 제공할 수 없지만 존재하지 않는 파일 이름은 정확히 같은 방식으로 처리되어야 합니다.

여러 가지 이상한 이유로 때때로 이 작업을 수행해야 했습니다.
이 사용 사례에서 API를 강화하려는 모든 사람에게 이 접근 방식을 제안합니다.

class ForceMultipartDict(dict):
    def __bool__(self):
        return True


FORCE_MULTIPART = ForceMultipartDict()  # An empty dict that boolean-evaluates as `True`.


client.post("/", data={"some": "data"}, files=FORCE_MULTIPART)

또는 도구 벨트를 사용하고 해킹에 의존하지 않을 수 있습니다.