Strange problem with rendering and reaction of web page
Some time ago, might be half a year all was OK. Some update in Leap 15.6 or the change to Leap 15.6 could have introduced the problem. I have a web page with a file index.html in which references are pointing to files, all in the same folder as index.html; a picture and a number of video files (.mp4). Css buttons either show the video or start a download. There is some css in index.html defining buttons with white characters and colored backgrounds. Also some text is indicated as white characters and colored backgrounds; different colors. When I use http:// to access this page, on a different apache server on a Tumbleweed server, all is displayed normal and the button used to play the video works as expected. I can position the location in the video from where to play the video. However using https:// to access the page the background of the characters is not colored and when I play one of the videos I am unable to select a position in the video to play from. It skips to the last position in the video. Some other videos give errors and do not play at all. The error shows something like: "No video with supported layout and MIME type found". In Firefox I used Page Source to download the content of the page, index.html. In both cases and apart from the obvious differences in the URLs pointing to the files they are the same. I should mention that I also used Microsoft Edge to access these pages and the same difference/problem is present. I am puzzled. Why is the rendering of the same content different and why is the reaction on playing the videos different. -- fr.gr. member openSUSE Freek de Kruijf
On 10/9/24 11:47 AM, Freek de Kruijf wrote:
When I use http:// to access this page, on a different apache server on a Tumbleweed server, all is displayed normal and the button used to play the video works as expected. I can position the location in the video from where to play the video.
However using https:// to access the page the background of the characters is not colored and when I play one of the videos I am unable to select a position in the video to play from. It skips to the last position in the video.
Some other videos give errors and do not play at all. The error shows something like: "No video with supported layout and MIME type found".
In Firefox I used Page Source to download the content of the page, index.html. In both cases and apart from the obvious differences in the URLs pointing to the files they are the same.
I should mention that I also used Microsoft Edge to access these pages and the same difference/problem is present.
I am puzzled. Why is the rendering of the same content different and why is the reaction on playing the videos different.
It sounds like your httpd-ssl.conf (or whatever name openSUSE uses for it) doesn't have the location for your "DocumentRoot" set correctly. Make sure the path to the document root matches what you have in httpd.conf. -- David C. Rankin, J.D.,P.E.
Op donderdag 10 oktober 2024 23:54:23 CEST schreef David C. Rankin:
On 10/9/24 11:47 AM, Freek de Kruijf wrote:
When I use http:// to access this page, on a different apache server on a Tumbleweed server, all is displayed normal and the button used to play the video works as expected. I can position the location in the video from where to play the video.
However using https:// to access the page the background of the characters is not colored and when I play one of the videos I am unable to select a position in the video to play from. It skips to the last position in the video.
Some other videos give errors and do not play at all. The error shows something like: "No video with supported layout and MIME type found".
In Firefox I used Page Source to download the content of the page, index.html. In both cases and apart from the obvious differences in the URLs pointing to the files they are the same.
I should mention that I also used Microsoft Edge to access these pages and the same difference/problem is present.
I am puzzled. Why is the rendering of the same content different and why is the reaction on playing the videos different.
It sounds like your httpd-ssl.conf (or whatever name openSUSE uses for it) doesn't have the location for your "DocumentRoot" set correctly. Make sure the path to the document root matches what you have in httpd.conf.
I got the suggestion to use F12 in Firefox to see error messages. It revealed that the Content-Security-Policy was set too strict. But even setting all to 'self' is too strict. Still trying to figure out what the right setting is. I explains why using localhost does not give the problem. I do not have a Content-Security-Policy for localhost. -- fr.gr. member openSUSE Freek de Kruijf
On 10/11/24 6:20 AM, Freek de Kruijf wrote:
I got the suggestion to use F12 in Firefox to see error messages. It revealed that the Content-Security-Policy was set too strict. But even setting all to 'self' is too strict. Still trying to figure out what the right setting is.
I explains why using localhost does not give the problem. I do not have a Content-Security-Policy for localhost.
That makes sense. My web-servers are on Arch, which simply sets all access restrictions through the conf files (and file ownership/permissions). If you are using a self-signed certificate, it makes sense to go ahead and get an actual ssl certificate from "Let's Encrypt" (it's free) and then you can use "certbot" to update it before it's 90 day expiration (they send you e-mail notices) If you run a mail-host, you can use the same ssl certificate for dovecot, etc.. That eliminates a lot of "nanny programs" that now refuse to talk to servers with self-signed certs. Up until about 5 years ago or so, self-signed certs are fine. -- David C. Rankin, J.D.,P.E.
Op zaterdag 12 oktober 2024 03:12:11 CEST schreef David C. Rankin:
On 10/11/24 6:20 AM, Freek de Kruijf wrote:
I got the suggestion to use F12 in Firefox to see error messages. It revealed that the Content-Security-Policy was set too strict. But even setting all to 'self' is too strict. Still trying to figure out what the right setting is.
I explains why using localhost does not give the problem. I do not have a Content-Security-Policy for localhost.
That makes sense.
My web-servers are on Arch, which simply sets all access restrictions through the conf files (and file ownership/permissions). If you are using a self-signed certificate, it makes sense to go ahead and get an actual ssl certificate from "Let's Encrypt" (it's free) and then you can use "certbot" to update it before it's 90 day expiration (they send you e-mail notices)
If you run a mail-host, you can use the same ssl certificate for dovecot, etc..
That eliminates a lot of "nanny programs" that now refuse to talk to servers with self-signed certs. Up until about 5 years ago or so, self-signed certs are fine.
I already have such things (Let's Encrypt) for quite some times. The Content-Security-Policy is something that can be enabled in the web server (apache) and has nothing to do with the use of http or https. It controls a.o. the use of CSS in a web page, even the use of CSS which is embedded in the web page (seems silly/unnecessary to me). It is required when you want a high rating on security on your web server. -- fr.gr. member openSUSE Freek de Kruijf
Op zaterdag 12 oktober 2024 15:26:17 CEST schreef Freek de Kruijf:
Op zaterdag 12 oktober 2024 03:12:11 CEST schreef David C. Rankin:
On 10/11/24 6:20 AM, Freek de Kruijf wrote:
I got the suggestion to use F12 in Firefox to see error messages. It revealed that the Content-Security-Policy was set too strict. But even setting all to 'self' is too strict. Still trying to figure out what the right setting is.
I explains why using localhost does not give the problem. I do not have a Content-Security-Policy for localhost.
That makes sense.
My web-servers are on Arch, which simply sets all access restrictions
through the conf files (and file ownership/permissions). If you are using a self-signed certificate, it makes sense to go ahead and get an actual ssl certificate from "Let's Encrypt" (it's free) and then you can use "certbot" to update it before it's 90 day expiration (they send you e-mail notices)
If you run a mail-host, you can use the same ssl certificate for dovecot,
etc..
That eliminates a lot of "nanny programs" that now refuse to talk to
servers with self-signed certs. Up until about 5 years ago or so, self-signed certs are fine.
I already have such things (Let's Encrypt) for quite some times.
The Content-Security-Policy is something that can be enabled in the web server (apache) and has nothing to do with the use of http or https. It controls a.o. the use of CSS in a web page, even the use of CSS which is embedded in the web page (seems silly/unnecessary to me). It is required when you want a high rating on security on your web server.
I analyzed it a bit further. It seems to have to do with CSS style elements outside the body of a html page, but in the header. The directive "default-src 'self'" is not enough in that case. It needs to be "default-src 'self' 'unsafe-inline'" -- fr.gr. member openSUSE Freek de Kruijf
On 10/15/24 4:20 AM, Freek de Kruijf wrote:
Op zaterdag 12 oktober 2024 15:26:17 CEST schreef Freek de Kruijf:
Op zaterdag 12 oktober 2024 03:12:11 CEST schreef David C. Rankin:
On 10/11/24 6:20 AM, Freek de Kruijf wrote:
I got the suggestion to use F12 in Firefox to see error messages. It revealed that the Content-Security-Policy was set too strict. But even setting all to 'self' is too strict. Still trying to figure out what the right setting is.
I explains why using localhost does not give the problem. I do not have a Content-Security-Policy for localhost.
That makes sense.
My web-servers are on Arch, which simply sets all access restrictions
through the conf files (and file ownership/permissions). If you are using a self-signed certificate, it makes sense to go ahead and get an actual ssl certificate from "Let's Encrypt" (it's free) and then you can use "certbot" to update it before it's 90 day expiration (they send you e-mail notices)
If you run a mail-host, you can use the same ssl certificate for dovecot,
etc..
That eliminates a lot of "nanny programs" that now refuse to talk to
servers with self-signed certs. Up until about 5 years ago or so, self-signed certs are fine.
I already have such things (Let's Encrypt) for quite some times.
The Content-Security-Policy is something that can be enabled in the web server (apache) and has nothing to do with the use of http or https. It controls a.o. the use of CSS in a web page, even the use of CSS which is embedded in the web page (seems silly/unnecessary to me). It is required when you want a high rating on security on your web server.
I analyzed it a bit further. It seems to have to do with CSS style elements outside the body of a html page, but in the header. The directive "default-src 'self'" is not enough in that case. It needs to be "default-src 'self' 'unsafe-inline'"
That's interesting. I've not revisited css rules in a number of years. You say: "CSS style elements outside the body of a html page, but in the header." Are you talking about external style-sheets referenced in the header? I ask because I haven't noticed a change over the past few years with, e.g. <link rel="stylesheet" type="text/css" href="/path/to/some.css"> I'm running apache 2.4.62 on the servers. Or are you referring to another type of CSS style elements in the page header? -- David C. Rankin, J.D.,P.E.
participants (2)
-
David C. Rankin -
Freek de Kruijf