Hi!
Alle anderen Dienste akzeptieren bislang die Umleitung auf https. Insofern wäre jetzt weather365 am Zuge....
Nein.
Die Meldung besagt nur, dass unverschluesselter Text (plain) zum https-Port (443) des Servers geschickt wurde.
Eine Weiterleitung auf https muss gar nicht erfolgen, denn lt. Vorlage werden die Daten ja direkt an den https-Port des Servers geschickt.
Das eigentliche Problem ist aber, dass die Daten im body des POST-Pakets erwartet werden und nicht in der URL.
Hier mal zum Vergleich zwei mitgeschnittene Pakete - damit man es besser erkennen kann (curl kann https) habe ich den curl-Aufruf gegen Port 80 des Servers laufen lassen:
WSWin:
Code: Alles auswählen
POST /stations/index.php?stationid=myID&datum=202103231232&utcstamp=1616499120&press=1023.3&t2m=7.2&relhum=76&windspeed=0.5&windgust=1.0&radi=49&uvi=0.0&rainrate=0.0&rainh=0.0&prec_time=60&raind=0.0&soilmoisture=38&dew2m=3.3&wchill=7.2&apptemp=5.4&heat=7.2&cloudbase=493&winddir=202&latitude=52.200000&longitude=13.233333&altitude=53&et=0.000&windrun=0.0+&soilmoisture2=48&leafwetness=0&leafwetness2=0 HTTP/1.0
Host: channel1.weather365.net
Accept: www/source, text/html, video/mpeg, image/jpeg, image/x-tiff
Accept: image/x-rgb, image/x-xbm, image/gif, */*, application/postscript
Content-type: application/x-www-form-urlencoded
Content-Length: 0
HTTP/1.1 400 Bad Request
Server: nginx
Date: Tue, 23 Mar 2021 16:00:56 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 264
Connection: close
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx</center>
</body>
</html>
Code: Alles auswählen
POST /stations/index.php HTTP/1.1
Host: channel1.weather365.net
User-Agent: curl/7.55.1
Accept: */*
Content-Length: 376
Content-Type: application/x-www-form-urlencoded
stationid=myID&datum=202103231232&utcstamp=1616499120&press=1023.3&t2m=7.2&relhum=76&windspeed=0.5&windgust=1.0&radi=49&uvi=0.0&rainrate=0.0&rainh=0.0&prec_time=60&raind=0.0&soilmoisture=38&dew2m=3.3&wchill=7.2&apptemp=5.4&heat=7.2&cloudbase=493&winddir=202&latitude=52.200000&longitude=13.233333&altitude=53&et=0.000&windrun=0.0+&soilmoisture2=48&leafwetness=0&leafwetness2=0HTTP/1.1 301 Moved Permanently
Server: nginx
Date: Tue, 23 Mar 2021 16:09:47 GMT
Content-Type: text/html
Content-Length: 178
Connection: keep-alive
Location: https://channel1.weather365.net/stations/index.php
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
Man erkennt im WSWin-Beispiel, dass die URL alle Daten enthaelt und das die content-length 0 ist. Genau dort sucht aber der Server nach den Daten.
Im Beispiel cURL sind die Daten eingekapselt im body (content-length = 376). Da die Daten an den http-Port gingen, erfolgt am Server der Redirect per 301 auf den https-Port. Das sollte hier jedoch keine Rolle spielen.
FOSHKplugin sendet die POST-Pakete (mit Daten im Body) an Port 80 - und das funktioniert tadellos.
Die Frage an Werner Krenn lautet: bietet WSWin die Moeglichkeit, die Daten statt in der URL im Body anzugeben?
Wenn nicht, muesste man bei weather365.net anfragen, ob sie den Server fuer die WSWin-Nutzer veraendern wollen - wovon ich tatsaechlich nicht ausgehe. Dann bliebe fuer die wirklich Willigen noch die Option, im WSWin eine passende Datei via Vorlage zu erzeugen und diese per externen Programm (wie z.B. curl) automatisiert hochzuladen. Eine automatische Dateigenerierung bietet WSWin ja. Und den Start eines beliebigen Programms im Intervall ja vermutlich auch, oder?
Ich versuche hier mal einen solchen Versuchsaufbau zu erstellen:
1. WSWin generiert eine Datei gemaess Vorlage im 5-Minuten-Intervall
2. WSWin startet im 5-Minuten-Intervall eine Batchdatei, die sich um den Versand der Daten aus 1 kuemmert
Oliver
