I'm having a mystery here. The issue itself is worked around by now, but I still can't see the actual cause: On our image sharing site Pixabay.com we recently implemented the srcset attribute for img tags on search results. You can see that in action here: https://pixabay.com/photos/
A typical img tag in there looked like this:
<img src="/image__180.jpg" srcset="/image__180.jpg 1x, /image__340.jpg 2x" alt="...">
It worked very well - for about 99% of all users. However, a few reported to see the issue depicted in this screenshot:
Some 30-50 images loaded correctly on the page, while the others resulted in broken images. We realized, our NGINX log contained a few errors like this:
open() "/.../image__180.jpg" srcset="/image__180.jpg 1x, /image__340.jpg 2x" failed (2: No such file or directory)
Apparently, for an unknown reason, the client requested the whole expression (value of src+"srcset"+value of srcset) as image path, which of course resulted in an error 404.
We played around a bit and realized, first providing the srcset and then the src attribute on the img tags solves the issue. No more error logs, no more complaints.
<img srcset="/image__180.jpg 1x, /image__340.jpg 2x" src="/image__180.jpg" alt="...">
I couldn't find any reports of this behavior anywhere on the web. But I'd like to learn more. Here's the discussion on Pixabay with several users reporting the issue: https://pixabay.com/en/forum/help-me-please-11/pixabay-technical-difficulties-1474/?pagi=2
Do you have an explanation?
There is absolutely no way for a browser to screw this up normally. HTML parsers are rock-solid, they don't randomly eat extra bytes for an attribute.
This is definitely a proxy or some other MITM screwing with the markup somehow. I suggest dropping in some JS that quickly examines all the src attributes on the page and checks if any contain "srcset", and if so, logging as much information as you can about the UA or whatever, so you can try to find a commonality between them.
Suspect it's probably some weird proxy examining/rewriting source, using a regex like /image.*.jpg/ and rewriting it back URL-escaped. That'll catch everything from the start of your src image up to the final .jpg in your srcset, and escape all the spaces and quotes between them so you get a single big src attribute value.
Alternately, since this is apparently delivered over HTTPS, which reduces the chance of proxy rewriting, it may be a badly-behaved extension.
We use CKEditor to construct emails. Now, when activating the smiley button, the smileys are actually added as
<img alt="smiley" src="<app>/script/webeditor/ckeditor/plugins/smiley/images/regular_smile.png" />
Of course, in an email we can not refer to an internal application URL. So, what are the options here?
Gmail solves this by adding the smileys as inline images of the email
Hotmail solves this by referring to images on a public location
I found documentation about 'BBCode-mode' of the ckeditor, which would add the smiley as [:-)] and let the application which shows the bbcode decide which picture to use.
there are HTML codes to show smileys, but browser support seems to be poor.
My question: which option to use? Are there already plugins available that handle one of those options? Ideally, something like BBCode should be available as valid HTML, supported by all browsers, maybe there is?
I can tell you how to do it with a fixed location for the images (like Hotmail). You have to set a config property like this:
config.smiley_path = "http://www.example.com/images/";
This should render
src="http://www.example.com/images/regular_smile.png"
I'm sending an e-mail newsletter in HTML.
Inside the HTML I have something like
<img height='70' width='70' style='display:block' src='myDomain.com/imageName.png'>
When I open the newsletter with Thunderbird or Outlook, the image is being displayed. However, when I open it with Gmail, no image is shown.
I'm not sure if it's about the proxy that Gmail uses for security reasons or if it's something else. Either way, I'd like to know if anyone ever came across this and if so, how it was solved.
Late to the party but here goes... I have experienced this problem as well and it was solved with the following:
Including the scheme in the src url (using "//" does not work - use full scheme EG: "https://")
Including width and height attributes
Including style="display:block" attribute
Including both alt and title attributes
EG:
<img src="https://static.mydomain.com/images/logo.png" alt="Logo" title="Logo" style="display:block" width="200" height="87" />
For me, the problem was using svg images. I switched them to png and it worked.
Google only allows images which are coming from trusted source .
So I solved this issue by hosting my images in google drive and using its url as source for my images.
Example:
with:
http://drive.google.com/uc?export=view&id=FILEID'>
to form URL please refer here.
Please also check your encoding: Google encodes spaces as + instead of %20. This may result in an invalid image link.
You might have them turned off in your gmail settings, heres the link to change them https://support.google.com/mail/answer/145919?hl=en
Also gmail may be blocking the images thinking they are suspicious.
from the link above.
How Gmail makes images safe
Some senders try to use externally linked images in harmful ways, but
Gmail takes action to ensure that images are loaded safely. Gmail
serves all images through Google’s image proxy servers and transcodes
them before delivery to protect you in the following ways:
Senders can’t use image loading to get information like your IP
address or location. Senders can’t set or read cookies in your
browser. Gmail checks your images for known viruses or malware. In
some cases, senders may be able to know whether an individual has
opened a message with unique image links. As always, Gmail scans every
message for suspicious content and if Gmail considers a sender or
message potentially suspicious, images won’t be displayed and you’ll
be asked whether you want to see the images.
Try to add title and alt properties to your image.... Gmail and some others blocks images without some attributes.. and it is also a logic to include your email to be read as spam.
I noticed that Google was stripping the src attribute from my img tags. I tried every answer on this page - with no luck.
What finally worked for me was replacing img tags with divs that have background images. For example, instead of:
<img style="height: 24px; width: 24px; display: block;" src="IMAGE SOURCE"/>
I replaced it with:
<div style="height: 24px; width: 24px; display: block; background: url(IMAGE SOURCE); background-size: contain;"></div>
Hope this helps others who spent way too long pulling their hair out over this.
In addition to what was said by Howard
You have to keep in mind that Google encodes spaces as +
To avoid this, the ulr must be encoded in RFC 3986, which means spaces encoded at %20, for example:
https://example.com/My Folder/image 1.jpg
to
https://example.com/My%20Folder/image%201.jpg
I had the same issue and for me it was because I was using an SVG image, once I changed to a JPG or PNG, it worked. Maybe this can assist someone who will come across the same issue. It seems Gmail doesn't support SVG images.
HTTP or HTTPS should be full address
background-image: url(http://fulladdress.com/ca/1/product_assets/T/C/X/M/K/NMTCXMK_mu.jpg)
var mailOptions = {
from: 'fulladdress#gmail.com',
to: emails,
subject: 'i super another ma node mailer cool test',
text: 'That was easy!',
html: '<div style="background-image: url(http://fulladdress.com/ca/1/product_assets/T/C/X/M/K/NMTCXMK_mu.jpg);width:500px;height:500px">ascfas</div>'
};
I know Gmail already fix all the problem above, the alt and stuff now.
And this is unrelated to the question but probably someone experiences the same as me.
So my web designer use "image" tag instead of "img", but the symptom was the same. It works on outlook but not Gmail.
It takes me an hour to realize. Sigh, such a waste of time.
So make sure the tag is "img" not "image" as well.
My issue was similar.
This is what my experience has been on testing the IMG tag on gmail
(assuming most of the organization's would have a dev qa and prod server.)
I had to send emails to customers on their personal email id's and we could see that gmail would add something of its own like following to src attribute of img tag. Now when we were sending these images from our dev environment they would never render on gmail and we were always curious why?
https://ci7.googleusercontent.com/proxy/AEF54znasdUhUYhuHuHuhHkHfT7u2w5zsOnWJ7k1MwrKe8pP69hY9W9eo8_n6-tW0KdSIaG4qaBEbcXue74nbVBysdfqweAsNNmmmJyTB-JQzcgn1j=s0-d-e2-ft#https://www.prodserver.com/Folder1/Images/OurImage.PNG
so an image sent to my gmail id as following never worked for me
<img src="https://ci7.googleuser....Blah.Blah..https://devserver.com/Folder1/Images/OurImage.PNG">
and our dev server we can't render this image by hitting following URL on Chrome(or any browser).
https://www.devserver.com/folder1/folder2/myactualimage.jpg
now as long as the src has www on it worked all the time and we didnt had to add any other attributes.
<img src="https://www.**prodserver**.com/folder1/folder2/myactualimage.jpg">
I was using Cloudflare. As soon as I disabled the proxy for my host's website IP address images in Gmail appeared immediately.
I have now added a new firewall rule to allow requests where the URI contains 'googleimageproxy' and everything is working fine.
I am even later to this party, but after spending about 2 hours trying everything imaginable and not having any luck, I finally realized it will work if I upload the pics to GOOGLE PHOTOS instead of GOOGLE DRIVE. Then I can right-click on the pic, copy the address, paste it in, and it works beautifully.
In backend i created endpoint for showing images. Laravel code looks like:
public function getImage($name)
{
return response()->file(base_path() . '/resources/img/' . $name . '.png');
}
Then in my html email template i created div with background-image.
<div style='background: url("https://mysite1.com/api/v1/get_image/logo")'></div>
And it's works for me.
I tried another image from internet which url starts https://
it worked on gmail and outlook.
get your images from domain which has SSL.
For me, the problem was using images name as equity investments.png . I switched them to equity_investments.png and it worked.
Not working :-
<img src="https://xxxxxxx.com/webinar_images/equity investments.png" alt="" />
Working :-
<img src="https://xxxxxx.com/webinar_images/equity_investments.png" alt="" />
I tried all the suggestions this thread (setting width, height, title, full url, etc). The final fix for me was switching from SVG to PNG did the trick for me.
I then tried removing all the other extra decorators (title, display block), and it still worked as long as I left the image type as PNG. So, PNG seems to be the only required change.
I do have the following code in my HTML:
<img src="#" alt="image alternative text" />
What does src="#" mean? Because in HTML, I cannot have empty src attribute for an image tag. And if we do not have that attribute, visual studio 2012 will throw a suggestion.
Thanks
When you don't want any image to be loaded using src attribute (probably load the image dynamically later), you need to set src empty. But when you do that, browsers still send calls to server.
Browser behavior for empty src (Source: http://developer.yahoo.com/performance/rules.html)
Internet Explorer makes a request to the directory in which the page
is located. Safari and Chrome make a request to the actual page
itself. Firefox 3 and earlier versions behave the same as Safari and
Chrome, but version 3.5 addressed this issue[bug 444931] and no longer
sends a request. Opera does not do anything when an empty image src is
encountered.
To avoid the unnecessary call to server, instead of using empty src, src="#" could be used which forms a hash url and hash urls are not sent to server.
Let's say base url is : http://mysite.com/myapp/
src="" -> Absolute url: http://mysite.com/myapp/
src="#" -> Absolute url: http://mysite.com/myapp/#
Most people use it as a placeholder for links just so that there are no errors when the code compiles. If a programmer gave you some code with the "#" as a placeholder, they probably want you to interchange it with a web URL.
As with the href attribute of an anchor element, <img src="#"> is roughly equivalent to <img src="thecurrenturl#" ..> (but see the fiddle example for why it's not identical).
As it is written src will never refer to a valid image resource but, presumably, something/someone can change the URL later or otherwise manipulate the element. Since the src attribute is required1, substituting in such a valid "dummy" value appeases tools like the Visual Studio editor.
This fiddle shows the behavior which can be observed by using the DOM src property.
1 "The src attribute must be present, and must contain a valid non-empty URL .."
More than likely just a placeholder subject to change dynamically based off of an event listener (or like #FabricioMatte suggested, a lazy loading technique.) It could also be just a placeholder to bypass any potential errors.
In src="#", the attribute value is a reference to the start of the document at the current base URL, according to the URL standard, STD 66 aka RFC 3986. You would need rather special arrangements to make that actually work as a reference to an image.
Why anyone would use such an attribute is a different question, and a yet another question is what is the problem that the construct is supposed to address.
i have 2 errors coming up on firefox. Theses errors are shown below.
1-there is no attribute "property". This refers to the line below:
<meta property="og:title" content="blahblahblah"/>
This is to do with linking it to social networks i.e facebook etc
2-there is no attribute onerror. This refers to the line below:
<img src="281.jpg" width="125" height="125" onerror="onImgErrorSmall(this)"/>
This basically displays a default image if the actual image dose not show up.
the question really is, i know these are not valid attributes but how can i get around them, if anyone has any ideas id be grateful.
For the meta tag there is no property attribute
For the img tag there is no attribute called onerror
No way to get around them as they are not part of the html markup
Live with them or remove - they will never validate against a web standard
You pasted stuff into a wysiwyg editor directly from Microsoft Office or OpenOffice document.
These properties are proprietary.
You should clean up or remove the markup before pasting. (Most of wysiwyg editors in use today have this function (a.k.a. paste from Word))
This link may be able to help you out.
onerror is only supported by the "browser" that Microsoft makes.