veit > internet.* > internet.www.ontwerp

 #1  
12.06.2018, 13:00
Sjoerd
Ik kwam deze pagina tegen van iemand die net als ik de Bluefish editor
gebruikt.

[..]

Klik links op een link onder 'LAW', bijvoorbeeld 'Grenslandpad'.
Op deze pagina komen een hele hoop foto's voor, maar ze worden niet
weergegeven in de browser. En mijn grote vraag is: waarom nou niet??

Kopieer ik de broncode (rechtsklikken > View frame source) en maak ik daar
een nieuwe pagina van, dan zijn de foto's ineens wel zichtbaar.

De url van al die foto's begint met [..]....
Klik je nou links op een link onder 'Buitenland', die beginnen ook
allemaal met [..].... en nu wil de pagina niet laden omdat
het een onbeveiligde verbinding zou zijn. Heeft het daar iets mee te
maken, dat die afbeeldingen op een onbeveiligde url zitten? En wat zou er
dan moeten gebeuren om die foto's wel goed weer te geven?

De site die ik zelf in beheer heb, wordt binnenkort ook overgezet naar
iets met SSL, SFTP, https enz. Om die reden probeer ik er iets van te
begrijpen.

Wel zie ik dat in de broncode een <!DOCTYPE html> ontbreekt, en er is wel
een afsluitende </head>, maar geen <head> aan het begin. Maar daar zal het
hem niet aan liggen.
 #2  
12.06.2018, 13:16
robert
Sjoerd <xx>:
[..]
> allemaal met [..].... en nu wil de pagina niet laden omdat
> het een onbeveiligde verbinding zou zijn. Heeft het daar iets mee te
> maken, dat die afbeeldingen op een onbeveiligde url zitten?


Min of meer. De server die "sisje.home.xs4all.nl" afhandelt stuurt deze
header naar de browser:

Content-Security-Policy: upgrade-insecure-requests

Dat betekent dat de browser resources (zoals plaatjes) die via HTTP moeten
worden binnengehaald automatisch moet upgraden naar HTTPS. Dus ondanks dat
er `http://` in de HTML staat, haalt de browser ze op alsof er `https://`
in de HTML stond.

En dan gaat het mis, want de server waar de plaatjes op staan heeft een
ongeldig (self-signed?) SSL certificaat.

> En wat zou er dan moeten gebeuren om die foto's wel goed weer te geven?


Misschien dat die header uit te zetten is (alhoewel ik vermoed van niet),
anders proberen om een geldig SSL certificaat op je server te krijgen óf de
plaatjes ergens anders hosten.
 #3  
12.06.2018, 17:24
Sjoerd
robert schreef:
> De server die "sisje.home.xs4all.nl" afhandelt stuurt deze header naar de
> browser:
> Content-Security-Policy: upgrade-insecure-requests
> Dat betekent dat de browser resources (zoals plaatjes) die via HTTP moeten
> worden binnengehaald automatisch moet upgraden naar HTTPS. Dus ondanks dat
> er `http://` in de HTML staat, haalt de browser ze op alsof er `https://`
> in de HTML stond.
> En dan gaat het mis, want de server waar de plaatjes op staan heeft een
> ongeldig (self-signed?) SSL certificaat.


Mijn dank. Zeer interessant allemaal.
 #4  
12.06.2018, 17:59
Rob
Sjoerd <xx> wrote:
> robert schreef:
> Mijn dank. Zeer interessant allemaal.


ALS dat al een correcte diagnose was dan klopt dat op dit moment in
ieder geval niet meer.
 #5  
12.06.2018, 18:03
robert
Rob <nomail>:
> Sjoerd <xx> wrote:
> ALS dat al een correcte diagnose was dan klopt dat op dit moment in
> ieder geval niet meer.


Ongetwijfeld zullen er voldoende browsers bestaan die zich niks aantrekken
van die header.
 #6  
12.06.2018, 18:34
Rob
robert <US3N37+{n.i.w.o}> wrote:
> Rob <nomail>:
> Ongetwijfeld zullen er voldoende browsers bestaan die zich niks aantrekken
> van die header.


Ik had het over:
 #7  
12.06.2018, 18:38
Rob
Rob <nomail> wrote:
> robert <US3N37+{n.i.w.o}> wrote:
> Ik had het over:


Ik zie nu dat er kennelijk meerdere servers in betrokken zijn, dat ga
ik niet verder uizoeken, klopt dan waarschijnlijk wel. De server van de
site zelf is OK in ieder geval.
 #8  
12.06.2018, 18:55
robert
Rob <nomail>:
> Ik zie nu dat er kennelijk meerdere servers in betrokken zijn, dat ga
> ik niet verder uizoeken, klopt dan waarschijnlijk wel. De server van de
> site zelf is OK in ieder geval.


Klopt, het gaat om de server die via IP-nummer wordt aangesproken, alleen
voor de plaatjes. Niet de XS4ALL server.
Soortgelijke onderwerpen