In the AngularJS docu you can see the following default header added to each request:
Accept: application/json, text/plain, * / *
I couldn't find what * / * means but I suppose it means ANY MIME TYPE.
Am I right? Sorry for the dumb question, but I couldn't find it explained anywhere...
Many thanks.
Yes. From the HTTP specification:
"The asterisk * character is used to group media types into ranges, with "*/*" indicating all media types"
You can read the whole spec in RFC 7231.
Yes, it means all mime types. As you can see at HTTP 1.1 Standards.
The asterisk "*" character is used to group media types into ranges,
with "*/*" indicating all media types and "type/*" indicating all
subtypes of that type. The media-range MAY include media type
parameters that are applicable to that range.
* / * actually is invalid; whitespace is not allowed here (and it was actually a bug in the angular documentation)
*/* however indeed means "any", see RFC 7231, Section 5.3.2 (https://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.5.3.2.p.2)
Related
I am new to MuleSoft
when i am giving output expression like below i am getting an data sense error, can you please help
#[output application/json --- {errorType:error.errorType, error:error.description}]
Description Resource Path Location Type Scripting language error on
expression '#[output application/json --- {errorType:error.errorType,
error:error.descrip...'. Reason: Invalid input '#', expected using,
if, ???, unless or not (line 1, column 1): . validations.xml
/validations/src/main/mule Listener Message Flow Error
It is hard to know without a snippet from the configuration XML exactly what your issue is, but one problem I see is that your dataweave does not start with a
"%dw 2.0" In mule 4 there are two languages. Mule Expression language, which is default in most components (ie #[vars.name] is MEL), and dataweave 2.0 which is default in Transform Message components. You can however, as you've attempted to do, use dataweave inside of Mule Expressions. You have it mostly right, but it must start with "%dw 2.0" at the beginning. So it should look like this.
#[%dw 2.0 output application/json --- {errorType:error.errorType, error:error.description}]
However, judging by the error message, it looks like you're attempting to use MEL in a place where it is not allowed. If you provide a snippet of the configuration XML for this component, I can be more helpful.
There is no MEL in Mule 4. It is migrated to DW2.0. Please refer link https://docs.mulesoft.com/mule-runtime/4.2/migration-mel
I need to save a file with correct MimeType for .p7m files (application/pkcs7-mime) via form upload to the server.
In the request I noticed that Content-Type is wrong:
------WebKitFormBoundaryaglEgtBJlb65v7d5
Content-Disposition: form-data; name="file0"; filename="getmymimeplease.p7m"
Content-Type: application/pkcs7
it should be:
Content-Type: application/pkcs7-mime
How is possible that the '-mime' part is missing (or truncated) ?
This is usually controlled by OS and/or Browser. On windows, this is set in the registry, in HKEY_CLASSES_ROOT\.<fileextension>, e.g. HKEY_CLASSES_ROOT\.p7m, in the Field Content Type:
So in the end, this is controlled by the client. So if there are several possible mime types for the same extension, you need to cover that in your server code (accept or decline, convert to your default or not)
I'm uploading a form with files, text etc to the appengine blobstore:
$http({
method: 'POST',
url: the_url,
transformRequest: formDataObject,
data: event,
headers: {'Content-Type': undefined}
})
The request sends successfully with the follwing header:
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryYeRxOO7y3qHNWd83
When I try setting the content-type to "multipart/form-data;charset=UTF-8" I lose the boundary and get an error in the response: Bad content type. Please use multipart.
What is the correct way to add the UTF-8 charset?
According to RFC 1341:
As stated in the definition of the Content-Transfer-Encoding field, no encoding other than "7bit", "8bit", or "binary" is permitted for entities of type "multipart". The multipart delimiters and header fields are always 7-bit ASCII in any case, and data within the body parts can be encoded on a part-by-part basis, with Content-Transfer-Encoding fields for each appropriate body part.
So you have to use Content-Transfer-Encoding instead of Content-Type in this case.
My solution was not to change anything:
It turns out using headers: {'Content-Type': undefined} was correct. Everything is now working (and I only changed the backend).
Trouble was that webob was ignoring encodings and hence I thought the encodings were wrong. Upgrading webob fixed this issue. The reason this was hard to detect was because the development server was using the new webob by default whilst the production was defaulting to an older webob version since the new version wasn't specified in app.yaml:
libraries:
- name: webob
version: "1.2.3"
the charset must be set after all like:
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryYeRxOO7y3qHNWd83; charset=UTF-8
I am using UW IMAP c-client v. 2007e and I couldn't find the following function: I need to retrieve a header of certain body part. I.e., the mail message contains multiple body parts, and one of them is an attachment looking like this:
--_004_57D6D2035A40B8ECEBA59CB9C13F52A1334093MBXC18_
Content-Type: text/plain; name="func.txt"
Content-Description: func.txt
Content-Disposition: attachment; filename="func.txt"; size=604;
creation-date="Thu, 12 Aug 2010 18:41:40 GMT";
modification-date="Thu, 12 Aug 2010 18:41:40 GMT"
Content-Transfer-Encoding: base64
...blah-blah-blah in base64...
Now, I can retrieve the blah-blah part with imap_fetchbody() but I don't see the function that can give me only the headers part (or headers+body, that would be OK too). I can get whole message text, but then I'd have to parse it myself into parts, which I don't want to do. Is there a way I could make c-client retrieve this header for certain part?
You want the MIME section of the part. From the IMAP RFC:
The MIME part specifier refers to the [MIME-IMB] header for
this part.
The c-client function for doing a FETCH is:
long imap_msgdata (MAILSTREAM *stream,unsigned long msgno,char *section,
unsigned long first,unsigned long last,STRINGLIST *lines,
long flags)
So if you want the headers from part 2.3 of message #8 (for instance), you'd call it as:
imap_msgdata(stream, 8, "2.3.MIME", 0, 0, null, FT_PEEK);
(FT_PEEK keeps the message from being marked as \Seen. If you want to mark the message read, pass 0 as the last argument.)
I was wondering what the mime type for iWork's Pages is? And also what the mime type is for the rest of the software in the iWork suite? I looked around online and I didn't see it anywhere.
I recently needed this for work and ended up just uploading some files and querying the mimetypes. I found the following:
keynote: application/x-iwork-keynote-sffkey
pages: application/x-iwork-pages-sffpages
numbers: application/x-iwork-numbers-sffnumbers
2021 Update
Please note that this answer is now outdated and the following content types have been approved by IANA:
application/vnd.apple.pages
application/vnd.apple.keynote
application/vnd.apple.numbers
Looks like Apple doesn't much care, since installing iWork does not add any mime type information to any of its system mime-type info reps (in /etc/cups and /etc/apache2), "Get Info" on an iWork file shows no mime-type, etc. The only hint I've found is in Page's info.plist (a copy's online here) which mentions:
<key>public.filename-extension</key>
<array>
<string>pages</string>
</array>
<key>public.mime-type</key>
<array>
<string>application/x-iwork-pages-sffpages</string>
</array>
and a similar one for filename-extension "template", with "-sfftemplate" as the suffix instead of "-sffpages".
application/vnd.apple.keynote
application/vnd.apple.pages
application/vnd.apple.numbers
Just got it approved with IANA. You will find the list at the below link.
https://www.iana.org/assignments/media-types/media-types.xhtml.
You can use mime-db https://github.com/jshttp/mime-db to validate using javascript
This URL shows some other types in case new readers need it:
Apache Jira Issue TIKA-588
application/vnd.apple.keynote, application/vnd.apple.pages, application/vnd.apple.numbers
Actually, those files are all a masked zipfile. So, some systems might indicate their mimetype simply as application/zip.