I'm trying to attach files by using the JIRA REST API on JIRA 5.
JIRA returns the 200 HTTP code, so it means everything worked fine (?) Nevertheless, the attached files are missing. No information about what happened neither in the log file nor anywhere.
However, it worked by uploading the files from the JIRA web client . Even worked fine by using the curl client. But NOT by using the Java HttpClient (logged in, added the X-Atlassian-Token: nocheck header, image/jpeg mime type and so on... those all details were reviewed)
Why does JIRA do? Why does it return 200?
I've found the... bug? or the poor implemetation? of the RFC 1867 on JIRA while inspecting the multipart output
>> Content-Disposition: form-data; name="file"; filename="Project Requirements.doc_page_6_6.jpg" >> Content-Type: image/jpeg
>> Content-Disposition: form-data; name="other thant file"; filename="Software Requirements Specification.doc_page_6_6.jpg" >> Content-Type: image/jpeg; charset=UTF-8 >> Content-Transfer-Encoding: binary
Thanks! This was the exact problem I was having using Postman. In the form-data body the "Key" field for my attachment needs to be "file", this maps exactly to the name attribute. I was getting 200 OK but the file was not being uploaded. I typed "file" into the "Key" field for the attachment and now it's working.
Thank you so much! This did the trick for me :)
MultiPart multiPart = new MultiPart();
FormDataContentDisposition formDataContentDisposition = FormDataContentDisposition.name("file").fileName(FILENAME).build();
FileDataBodyPart fileDataBodyPart = new FileDataBodyPart("file",
Headers taken from curl output:
> POST /jira/rest/api/latest/issue/TEST-39/attachments HTTP/1.1 > Authorization: Basic YWRtaW46YWRtaW4= > User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/188.8.131.52 libidn/1.23 librtmp/2.3 > Host: toshi:2990 > Accept: */* > X-Atlassian-Token: nocheck > Content-Length: 8112 > Expect: 100-continue > Content-Type: multipart/form-data; boundary=----------------------------f60a0cc2c9ef
Headers taken from HttpClient output:
>> POST /jira/rest/api/latest/issue/TEST-39/attachments HTTP/1.1 >> Cookie: $Version=0; atlassian.xsrf.token=BP8Q-WXN6-SKX3-NB5M|cf5b539374e2a1434882067e95c46d1eb801ce50|lout; $Path=/jira >> Cookie: $Version=0; JSESSIONID=7FE086588C53827CF7B4B70FCAC777B7; $Path=/ >> User-Agent: Jakarta Commons-HttpClient/3.1 >> Host: toshi:2990 >> X-Atlassian-Token: nocheck >> Content-Length: 10186 >> Expect: 100-continue >> Content-Type: multipart/form-data; boundary=Et-PrNk5xMYZkRDRSR9vMoLzqhFQVfsMGahEm1S
Both are equivalent and JIRA sends back:
HTTP/1.1 100 Continue
Then both, curl and httpclient upload the file data and receive a
HTTP/1.1 200 OK
HttpClient 3.1 is multipart/form-data RFC 1867 compliant, so I don't see much reasons about the JIRA behaviour.
Teams break work down in order to help simplify complex tasks. This is often done iteratively, with tasks being broken down into smaller tasks and so on until the work is accurately captured in well-...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events