We're facing an issue (http response 415 trying to create an attachment in JIRA). Can you please help resolve our issue? Steps we followed in webMethods
1) getFile load as stream
2) pub.mime:createMimeData
3) pub.mime:addBodyPart (pass the stream from step1 as input, and not setting the content type; we've tried setting application/octet-stream with same results ).
4) pub.mime:getEnvelopeStream.
5) pub.io:streamToString (to verify the Mime created in step 4)
6) pub.client:http (passing envStream creted from step4 to data/mimeStream and loadAs "stream"
Step5 output
Message-ID: <508725916.27.1498892350039.JavaMail.webmethods#bisawswmindv01>
MIME-Version: 1.0
Content-Type: multipart/form-data;boundary="------defined------";name=file;filename=sample.txt
X-Atlassian-Token: nocheck
Authorization: Basic d2AiobWV0aG9kczpBMTJzcjcxYmI=
------=_Part_26_16733932.1498892350039
Message-ID: <1774613176.25.1498892350038.JavaMail.webmethods#bisawswmindv01>
MIME-Version: 1.0
content-type: text/plain
content-transfer-encoding: 7bit
this is a test file: this is a test file
------=_Part_26_16733932.1498892350039--
415 error code is for Unsupported Media Type means,
The request entity has a media type which the server or resource does not support. For example, the client uploads an image as image/svg+xml, but the server requires that images use a different format.
Looks like media type of the attachment you are uploading is not supported by JIRA.
Related
I'm uploading a screenshot failure png to Test Rail via their API - Here's the code that works in 106:
Request = new RestRequest("/index.php?/api/v2/add_attachment_to_result/85)
.AddHeader("Content-Type", "multipart/form-data")
.AddFile("attachment", "C:\Source\screenshot.png");
IRestResponse AddAttachmentResponse = Client.Post(Request);
The only thing I changed after the upgrade to v107 is the last line:
RestResponse AddAttachmentResponse = Client.PostAsync(Request).GetAwaiter().GetResult();
I now get an error back from the Test Rail API "Bad Request" - here's the documentation on their API: Test Rail Add Attachment API doc - I know the http engine has changed in 107 - what do I need to do differently now?
UPDATE:
It appears that v107 is not sending the Content-Type in the header - here's the output from HttpTracer:
==================== HTTP ERROR REQUEST: [POST] ====================
Authorization: Basic TokenRemoved
Accept: application/json, text/json, text/x-json, text/javascript, *+json, application/xml, text/xml, +xml, *
User-Agent: RestSharp/107.1.1.0
Accept-Encoding: gzip, deflate, br
Cookie: tr_session=7cef485e-1aca-46bb-a773-9d9f5d410ee6
--8eef1c58-a3df-4ddb-a1c5-e081ccf90709
Content-Type: application/octet-stream
Content-Disposition: form-data; name=attachment; filename=Untitled.png; filename=utf-8''Untitled.png
snipped for brevity
Note there is a Content-Type in the body, but none in the header.
Issue link: https://github.com/restsharp/RestSharp/issues/1713
As we discussed, HttpTracer only shows the request headers, and Content-Type is the request header.
When debugging this issue (and a couple of other related issues), we found out that the issue was caused by the server not being able to handle name and filename parameters in the form part (Content-Disposition header) if they are not wrapped in quotes. Strangely enough, adding content disposition directly using ContentDispositionHeaderValue doesn't add quotes by default. After adding them manually it started to work:
fileContent.Headers.ContentDisposition = new ContentDispositionHeaderValue("form-data") {
Name = $"\"{file.Name}\"",
FileName = $"\"{file.FileName}\""
};
My answer is for anyone who experienced a similar issue with 107.1, the latest alpha and the next stable version should handle this properly.
We are using Chilkat 9.5.0.80 C++ library.
There is a certain HTTP header we cannot add to our requests: "Content-MD5". When we add this header like this:
m_ckRest.AddHeader("Content-MD5", "any-value-here");
and examine the resulting request*, the "Content-MD5" header is NOT present.
However, when we add a header of a different name:
m_ckRest.AddHeader("Content-Type", "application/octet-stream");
... the resulting request DOES contain that header. We are using the "fullRequestBinary" method, for example:
const char* responseStrPtr = m_ckRest.fullRequestBinary( "PUT", encodedObjectName.c_str(), ckByteDataBuffer);
* We are examining our requests using a Proxy (using "Fiddler" as an http proxy in between us and Amazon S3 for example to test the upload of a "part" in a multipart AWS S3 upload) and in every attempt, the "Content-MD5" header is NOT present, while other headers are present.
Is this a bug? We found an old forum post from 2013 referencing a very similar sounding problem: http://www.chilkatforum.com/questions/2901/addheader-range-does-not-appear-to-be-effective Does Chilkat remove or ignore our attempt to add a "Content-MD5" header? Is this bug fixed in a version newer than the one we are using? Is there a workaround? Here is an example of the headers in a PUT request:
PUT https://our-bucket.s3.us-west-1.amazonaws.com/somefile?partNumber=4&uploadId=tJJYIXdxG_7X8elzSJrKt32A_rH46Y0Yk1vyzZgwxpvmK5uCrcE82k_F9UmytVHWuxXfc6tX5o3w.SRnnYcD7VBskcLrr0xC13bHHVDx62iGGQ3eIzkv5J5d1F4_DkcW HTTP/1.1
Content-Length: 5266235
x-amz-date: 20200921T201943Z
x-amz-content-sha256: 90fa8fc564dd558d0c2eac92e367d94101f4ca9570c970795b9fdb2aa96d6666
Host: our-bucket.s3.us-west-1.amazonaws.com
Content-Type: application/octet-stream
Date: Mon, 21 Sep 2020 20:19:43 GMT
Authorization: AWS4-HMAC-SHA256 Credential=AKIAIBYS55OSD2FIOBFUS/20200921/us-west-1/s3/aws4_request,SignedHeaders=content-type;host;x-amz-content-sha256;x-amz-date,Signature=8ea74cb7769d8e158e5ccc0604cc2cdb096703b10c3c8d9323d0746debbdUUU
In correspondence with Chilkat support, turns out that Chilkat versions 9.5.0.80 and 9.5.0.83 intentionally remove the Content-MD5 header when authenticating using AWS Signature V4. Instead, Chilkat calculates the SHA256 hash and places it in the x-amz-content-sha256 (if authenticating using older AWS signature V2, it calculates Content-MD5 I'm told) So, unlike the comment from #Chilkat Software, this has not been fixed in a later version as of the writing of that comment, and the removal is intentional.
This is not terrible, but it stems from the misunderstanding that a SHA-256 hash of the content is necessary to construct a valid AWS Signature V4 for authentication, when in fact that is not the case. While SHA256 is perfectly adequate for content verification, it is also wasteful in comparison to MD5 for content verification.
The AWS C++ SDK itself does not use a SHA-256 hash in the x-amz-content-sha256 header when uploading a part. I've confirmed it uses: x-amz-content-sha256:UNSIGNED-PAYLOAD and instead uses the less "costly" MD5 hash, and puts it in the Content-MD5 header (see AWS documentation here https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html)
Unsigned payload option – You include the literal string
UNSIGNED-PAYLOAD when constructing a canonical request, and set the
same value as the x-amz-content-sha256 header value when sending the
request to Amazon S3
Here is an example of an Amazon AWS UploadPart request using Content-MD5 for conent verification, and NOT using SHA256 for signing the request (captured from request using AWS SDK for C++):
PUT https://mybucket.s3.us-west-1.amazonaws.com/somefile.mfs01?partNumber=1&uploadId=6CHL6tPKFcRSoxD4iysjKMgQCNfcFAt87bn4fsduV1YI5_aFIz9e36BxFURH_iEX8EChUtQm06qT9oyIUDbAnA.2M.novpBBKsnGl_NqNvVllQ7L1VK6x1PiLlqq46tH HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Content-Type: binary/octet-stream
Content-MD5: PV204S0m8zJY8zu9Q3EF+w==
Accept: */*
Authorization: AWS4-HMAC-SHA256 Credential=AKIAIBYS55OSD2FOBFUSC/20200923/us-west-1/s3/aws4_request, SignedHeaders=amz-sdk-invocation-id;amz-sdk-request;content-length;content-md5;content-type;host;x-amz-content-sha256;x-amz-date, Signature=d013028d77e45f3dcce5f46f3fb53cdeeb3c9cfbd931371e69a9925047e61cd3
Host: nuix-nov-dev.s3.us-west-1.amazonaws.com
User-Agent: aws-sdk-cpp/1.7.333 Windows/10.0.19041.329 x86 MSVC/1927
amz-sdk-invocation-id: E57D09A7-B5E7-4E2A-8B2D-B493147F06D7
amz-sdk-request: attempt=1
x-amz-content-sha256: UNSIGNED-PAYLOAD
x-amz-date: 20200923T212738Z
Content-Length: 5242880
Chilkat gave us a new "beta" build that allows us to specify the Content-MD5 header even for AWS Signature V4 and it won't remove it, however, it's in addition to the automatically calculated SHA-256 x-amz-content-sha256 so that's doubling the hashing unnecessarily, and would be better to be able to specify UNSIGNED-PAYLOAD for purposes of the AWS signature.
If there is a content mismatch error with the Content-MD5 value, AWS returns this (with a status 400):
<?xml version="1.0" encoding="UTF-8"?>
<Error>
<Code>InvalidDigest</Code>
<Message>The Content-MD5 you specified was invalid.</Message>
<Content-MD5>thisisbad</Content-MD5>
<RequestId>8274DC9566D4AAA8</RequestId>
<HostId>H6kSy4cl+54nMon1Hq6AGjmTX/MfTVMQQr8vEVNXUnPlfMtIt8HPdObfusckhBpwpG/CJ6ORWv16c=</HostId>
</Error>
If there is a content mismatch with x-amz-content-sha256 AWS returns the following error, which I had difficulty finding on the web, and is slightly different so pasting here (also status 400):
Status:400 : AWSCode: XAmzContentSHA256Mismatch : AWSMessage: The provided 'x-amz-content-sha256' header does not match what was computed.
This problem should have already been fixed in a later version of Chilkat.
I´m trying to get a file upload to my JAX-RS controller working with multipart. I´ve been using the integrated REST HTTP Client of IntelliJ, that is recommending me to switch to the new HTTP Client by using .http files.
However, once I´m doing that I´m unable to do any uploads and I´m running into this exception
exception
java.io.IOException: RESTEASY007550: Unable to get boundary for multipart
request.http
POST http://localhost:8080/content/upload
Accept: */*
Cache-Control: no-cache
Accept-Encoding: multipart/form-data
--null
< path/to/my/file
--null--
What is the correct syntax for performing multipart uploads?
Here's my .http file. Worked.
POST http://127.0.0.1:8000/v1/dataSource/1/table/
Content-Type: multipart/form-data; boundary=WebAppBoundary
--WebAppBoundary
Content-Disposition: form-data; name="csv_files"; filename="insight_modeling_base_node.csv"
< /home/core/Code/work/KG_test/data/insight_modeling_base_node.csv
--WebAppBoundary--
In your case, try adding boundary=null. Or just copy what I pasted here and make some adaptation.
I'm sending a request to server service called path-generator which gives me a generated url and I'm uploading images to this url which moves the images to s3 bucket.
I'm able to upload the file to the bucket, but it arrives as broken image (when i'm uploading the file with 'Accept: application/json, text/plain' header)
or as 'Content-Transfer-Encoding: binary' when not using the header
The requests:
With header:
Connection: keep-alive
Content-type: image/png
Accept: application/json, text/plain
:
Content-Length: 201571
Host: {some host}
User-Agent: Apache-HttpClient/4.5.6 (Java/11.0.1)
without header:
Connection: keep-alive
Content-type: application/json
Content-Length: 221702
Host: {some host}
User-Agent: Apache-HttpClient/4.5.6 (Java/11.0.1)
I'm using the exact same flow as the client so it must be something wrong I'm doing with Jmeter
When you tick Use multipart/form-data box JMeter doesn't use Content-Type header specified in the HTTP Header Manager, most probably this is the reason for your request failure.
Try recording the file upload request using HTTP(S) Test Script Recorder (make sure to copy the file to "bin" folder of your JMeter installation) to see if JMeter is capable of properly capture the upload request(s). If it is - you should be good to go. If not - you will have to amend JMeter configuration to 100% match request specification, check out Testing REST API File Uploads in JMeter article for example test plan.
S3 PUT requests only need file content and no extra fields.
Do not pass parameter name and MIME type, only pass filePath correctly. If required add header Content-Type: image/jpg or video/mp4 in case it's a video. Similarly for pdf, text, etc.
Additionally, when you download the broken file and open it in notepad++
along with the actual file which was used to upload in notepad++
you can see the difference: the broken file has some extra text in it. If you remove it, it will work as expected
Also do not try this is notepad, use notepad++ only.
I would like to be able to attach a file to a conversation, using the REST API. Is it possible? There is a «attachments» to /conversations/{convId}/messages/{itemId} but is that usable? How? The description of that field is not available.
The file API of Circuit supports the upload of attachments. As soon as you received your access token you can POST a message with the byte data. The following example wold upload a file with name test.jpg
POST /rest/v2/fileapi HTTP/1.1
Host: local.circuit.com
Authorization: Bearer <access token>
Content-Length: 100
Content-Disposition: attachment; filename="test.jpg"
Cache-Control: no-cache
<your content in binary form here>
Usually I am using Postman for my tests since it is very easy to use and supports OAuth 2.0 token generation (https://www.getpostman.com/)
You will receive an result that looks like
{"fileId":"fb211fd6-df53-4b82-824d-986dac47b3e7","attachmentId":"ZmIyMT..."}
If you want to validate your upload you can check it via
GET /rest/v2/fileapi?fileid=fb211fd6-df53-4b82-824d-986dac47b3e7 HTTP/1.1
Host: local.circuit.com
Authorization: Bearer <access token>
Cache-Control: no-cache
Well that was the easy part, now that you have uploaded the file to the backend you must attach it to a conversation item. Today we do not support UPDATE, i.e. you need to create a new one.
POST /rest/v2/conversations/<conv ID>/messages HTTP/1.1
Host: local.circuit.com
Authorization: Bearer <access token>
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
content=New+Text+Message&attachments=ZmIyMT...
You have to pass the generated attachment ID. After the execution of this requests the file is attached to the conversation.
If you skip the second step the file will not be linked to any conversation, is only accessible by the user who initiates the upload and will be deleted within the next 24 - 48h automatically.
Hope this helps, let me know if you have additional questions.