I'm sending a mail template and it's not rendering UTF-8 characters correctly only on Yahoo Mail, which is quite weird.
MJML is adding by default utf-8 charset tag, I have not changed this default, and it's correctly appearing in the source code of the mail.
Do you have an idea of what could be wrong?
The issue was caused by my client client which was not correctly sending the HTML header.
I managed to send Content-Type: text/html; charset=UTF-8 and it's now working fine in Yahoo Mail 👍🏻
Related
So, I have wasted half a day with this and I am not getting anywhere.
I have a German application where I am sending a POST request and keep getting 415 Unsupported Media Type in Postman.
The same request works fine in UI and strangely in JMeter which is pretty much similar to Postman. I have tried all possible solutions listed in the internet including setting Content-Type (application/json, application/json,charset=utf-8) and Accept in the Headers yet the same results.
Here is my request Header in Postman
and the same request Headers in JMeter where it works (the only difference is I set the Encoding in a different place in JMeter and not in the Header and if I set it in the Header, I get a 400 instead of a 415)
Does setting the Content Encoding behave differently in JMeter? the Only place right now where I can set the encoding in Postman is through the Content-Type and that doesn't seem to work.
one of the request of my web page is to retrieve the html panel data. This request is triggered with the help of java script from browser. The response received from the server include caching headers that are confusing. The headers received are like - Cache-Control:"private, max-age=120no-store"
in this expected is max-age=120 header but we are getting no-store header as well which is causing the response not to remain cached.
Can anyone let me know what all we can do to avoid the no-store in the cache-control header?
As max-age and no-store are not separated by any separator, what we can do to know what is causing them to appear in this format and fix the issue?
I am trying to create an app with Cordova which receives push notifications from my server. Can anyone tell me that I need a https:// connection for the APNS to work or it should work with http:// as well?
All FCM/GCM endpoints are https, the same endpoints are used whether you are sending to Android, iOS or web so you should always use https when sending messages through FCM/GCM.
Based from this documentation, the sample POST request should be https://gcm-http.googleapis.com/gcm/send.
A message request is made of 2 parts: HTTP header and HTTP body.
The HTTP header must contain the following headers:
Authorization: key=YOUR_API_KEY
Content-Type: application/json for JSON; application/x-www-form-urlencoded;charset=UTF-8 for plain text. If
Content-Type is omitted, the format is assumed to be plain text.
The HTTP body content depends on whether you're using JSON or plain
text.
You can follow this tutorial.
We have uploaded an mp4 video file into our Magnolia DMS, which fails to play on Safari (Mac/iPad). Investigation shows that the Content-Type returned by Magnolia is "application/octet-stream" for the request. When serving the file through Tomcat directly, the correct Content-Type "video/mp4" is returned and video playback works.
How can we configure the content-type to be returned in Magnolia?
We know the content-type is a function of the request (e.g. if we add ".jpg" to the URL the type returned is "image/jpeg"), but couldn't use this knowledge to come up with a solution.
Update:
We found the MIME configuration and could change the Content-Type for "mp4" to "video/mp4". However, the Content-Type returned by Magnolia is now
Content-Type: video/mp4;charset=UTF-8
while the correct, working Content-Type returned for files hosted by Tomcat is
Content-Type: video/mp4
Is it possible to make Magnolia not append any charset info to the Content-Type?
Glad you found the MIME configuration OK.
Both the MIME type and the character encoding are set in ContentTypeFilter.java and MIMEMapping.java. You can specify a charset for a MIME type yourself by including it in the mime-type definition. (E.g. "video/mp4;charset=UTF-8".)
If you don't include one, however, Magnolia automatically assigns the default (in this case, UTF-8). If you want to change this behavior, you'd need to tweak the source code.
Out of curiosity, is the charset causing you any trouble, or are you just trying to get Magnolia to match what Tomcat does by default?
I am using Railo 3.0 for a web application (setup exactly the same as this excellent guide). I have a CFM page that serves up some old HTML files using the cfcontent tag. This content is in various character sets (all defined as meta tags in the HTML). The problem is that all my CFM pages are getting sent out with UTF-8 set in the HTTP response headers, and this overrides anything defined in the HTML. The pages therefore get displayed incorrectly in the browser.
How can I stop the charset being sent in the HTTP headers for CFM pages?
Notes:
I've removed the AddDefaultCharset entry from the default Apache config, and this means that static HTML pages are now served without any charset in the header, however this didn't help for CFM pages - AddDefaultCharset is bad, bad, bad
I know this is an old thread, but I have had a similar issue recently and overcame it using the underlying java servlet context. If you get hold of the ServletResponse you can call .reset(), which according to the Java docs says:
Clears any data that exists in the buffer as well as the status code and headers.
You'll need to rewrite ALL the headers from scratch, but it will clear the rogue charset header.
<cfset objResponse = GetPageContext().getResponse()>
<cfset objResponse.reset()>
This works in Railo. In CF (Adobe) I think you need to call getResponse() twice to get hold of the appropriate response object.
Hope that helps someone.
what charset are you trying to send the pages out as? you can force the charset of the page a couple of ways:
<cfprocessingdirective pageEncoding="windows-1252">
http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=Tags_p-q_13.html#2962107
<cfheader name="charset" value="windows-1252">
http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=Tags_g-h_07.html#3989067