Abhijit Sarkar opened SPR-15948 and commented
Using 5.0.0.BUILD-SNAPSHOT, not RC3.
I understand that #19114 added multipart support for WebClient, and I also looked at the integration tests, but sadly, it doesn't work for the following request made using WebClient.
curl -v --trace-ascii /dev/stdout -F board=sarkara1/test -F note=test -F image=@test.png "https://api.pinterest.com/v1/pins/?access_token=xxx"
I keep getting the error "400 board is required" from the server. I'm not saying Pinterest API is the best designed in the world, actually it's quite the contrary, but the above curl statement works, and so does an OkHttp client, so I've to believe that it's a bug with WebClient.
By dumping the request body, and comparing it with those from the working versions, I've noticed that WebClient adds a Content-Type: text/plain header for simple form fields like board and note above, while the other clients don't. If I remember correctly, WebClient also adds a ;utf-8 after the overall Content-Type boundary, which the other clients don't. There may be other differences that I'm failing to report now, since it was done in a caffeine-fuelled, late-night, debugging session. Also see #20500 which is adding to the differences.
Affects: 5.0 RC3
Issue Links:
0 votes, 5 watchers
Abhijit Sarkar opened SPR-15948 and commented
Using 5.0.0.BUILD-SNAPSHOT, not RC3.
I understand that #19114 added multipart support for
WebClient, and I also looked at the integration tests, but sadly, it doesn't work for the following request made usingWebClient.I keep getting the error "400 board is required" from the server. I'm not saying Pinterest API is the best designed in the world, actually it's quite the contrary, but the above
curlstatement works, and so does anOkHttpclient, so I've to believe that it's a bug withWebClient.By dumping the request body, and comparing it with those from the working versions, I've noticed that
WebClientadds aContent-Type: text/plainheader for simple form fields likeboardandnoteabove, while the other clients don't. If I remember correctly,WebClientalso adds a;utf-8after the overallContent-Typeboundary, which the other clients don't. There may be other differences that I'm failing to report now, since it was done in a caffeine-fuelled, late-night, debugging session. Also see #20500 which is adding to the differences.Affects: 5.0 RC3
Issue Links:
0 votes, 5 watchers