Here I am getting a response from my api but the thing is I am getting(downloading) the file by the name CAT-L489-H342 which is without any extension.
What I want the response name to be like this Datasheet-CAT-L489-H342.pdf as I am getting the response in the form of pdf which is downloading too.
Can anyone help me in this situation?
I tried using Content-Type= application/pdf
actual- CAT-L489-H342
expected- Datasheet-CAT-L489-H342.pdf
Related
I have a react webapp that calls an api (that calls another api using fetch) for image urls and renders the images on the screen through img tags.
The issue I'm having is that the images don't load and instead i get a CORB warning in the console.
Cross-Origin Read Blocking (CORB) blocked cross-origin response
https://website.com
with MIME type text/html. See
https://www.chromestatus.com/feature/5629709824032768 for more
details.
Notice that im having an issue with CORB not CORS A lot of online posts just give the soluton of adding stuff to the headers which may solve CORS issue but i don't believe they solve CORB. In any event, the api i'm using is not mine so i wouldn't be able to add anything server side anyway.
Do i need to add something to my project client side to get this to work? Any ideas would be appreciated.
That happens because the type you requested does not match the data type that is responded from the server. to overcome this try to compare the two. But, if you doesn't have access to target server, You can make a proxy to the destination server. create one more server that will edit the response header from example.com
Example:
Client App => Your proxy server with modified Content-Type header (Ex: http://myproxy.com) => Your destination server (Ex: http://example.com)
Or if you don't want to create a new server and the application is only opened by you personally, you can replace your browser with a version that doesn't yet apply CORBS.
There is no other attempt I know for the client besides that.
I have problems to upload attachments to JIRA REST API using HTTP POST with the HTTP action. It works with text files (Content-Type: text/plain) but when I'm posting other files such as PDF and images the files are not uploaded correctly; they get the wrong file size and are not readable.
I assume it's a problem with the encoding. I've tried to use the binary function on the file contents but it does not help. According to JIRA the REST API doesn't accept base64-encoded files.
Have anyone of you been successful in posting attachments (other than text files) to JIRA or another API?
I found how to do it. The body of the HTTP request should contain special attributes for Multipart and Content-Type as described here: https://learn.microsoft.com/en-us/azure/connectors/connectors-native-http#content-with-multipartform-data-type
So the HTTP POST should look like this:
I have seen the API documentation still not getting it. Could someone give me the following :
1) The exact URL which I should use
2) The headers which I should use exactly
3) The Body Request which I should use
Could someone help me with it ??
For me worked: adding the attachments to the raw body of the request to the endpoint: https://www.googleapis.com/gmail/v1/users/userId/messages/send. This is tested with files up to 25MB.
I also couldn't figure out how to use the upload endpoint.
To add the attachment to the raw body i add a new Mime part (to the multipart/related) of type the same as the attachment mime type and you also need to add the Content-Disposition header to set if the attachment is inline or attached.
You can check here for more information on MIME messages:
https://www.qcode.co.uk/post/70
I had an existing POST API which was used to sent an object to server. Now I want to attach a file to the header of the same file. Is it possible to do such a thing. Can a request have multiple content-type.
I tried using ngFileUpload directive, and provide my object to data field of Upload.upload method. However, by doing this the entire data object seems to go in header and the request fails.
Any suggestions for sending file in headers and JSON in request body of a POST call??
I eventually found out that a HTTP request can have a single Content-type. This is as per the standards. However it is still possible and quite easy to send data along with a file using the FormData Object. The support for FormData though is not across all the versions of various browsers.
I have written a pretty simple API in PHP and am running it as a service (https://protoapi-dot-rehash-148415.appspot.com/events/).
When I try to load a data grid with the JSON from the API, I am getting the dreaded "No 'Access-Control-Allow-Origin' header is present on the requested resource." error on the page on which I want to consume the JSON. (http://proto-angular-dot-rehash-148415.appspot.com/events.php)
I've tried a couple of different methods to add Access-Control-Allow-Origin: "*" to the app.yaml file and to the header in the PHP file that produces the API. I think it doesn't work in the yaml because you cannot apply http_headers to dynamic files, and it doesn't work in the file because of the compression.
Is there any other way to make this work, short of putting the API and the app in the same service? I'd hate to do that because I am using mod_rewrite for the API and it will probably cause chaos on my app.
Any insights would be greatly appreciated!
-Mike
The header won't do any good unless you add it server-side, on the events API. The server is what dictates CORS permissions. You could send it messages or files all day with the right headers at the top and it will just ignore them. The allow-origin header has to come from the server to allow the cross-origin resource sharing (CORS) to take place.
I would recommend prepending the header in the function that offers up the API or handles the requests. Your events API spits out a lot of JSON. Right before that JSON, have your API spit out the header Access-Control-Allow-Origin: * and you should be all set.
As a sanity check you can also try adding Access-Control-Allow-Headers: Content-Type and see if that helps. Based on your comment about the Content-Type header, this may be part of the problem. It should be added the same way as the other one; have your API send it prior to your events JSON on its own line (put a \n to make a new line inside the string literal).