Hauptmenü

jsonP - Request

Begonnen von tiptronic, 09 Januar 2012, 11:54:05

Vorheriges Thema - Nächstes Thema

Guest

Originally posted by: <email address deleted>

Hallo!

Am Mittwoch, 5. September 2012 12:34:17 UTC+2 schrieb gaggi:
>
> Ich hab die 01_FHEMWEB.pl nochmal überarbeitet um CORS auch bei
> aktiviertem basic auth benutzen zu können.
> Außerdem noch ein Patch für das Eltako FSM61 EnOcean Modul um released als
> Status zuzulassen.
>

Ich möchte die Diskussion zu JSONP auch nochmal aufgreifen und zwei Patches
vorschlagen:

jsonp-newlines.patch:
JavaScript mag keine String-Definitionen über mehrere Zeilen. Daher
beschwert sich der Browser bei der bisherigen JSONP-Funktion, wenn es
mehrzeilige Ausgaben (z.B. von jsonlist) gibt. Man kann die Zeilenumbrüche
aber einfach mit \ vor dem Zurückschicken escapen. Danach funktioniert das
JSONP mit Firefox, IE 9 und Opera.

jsonlist-devicedetails.patch
Die Ausgabe von jsonlist ohne Parameter und mit einem Typ als Parameter ist
ein Objekt mit den Attributen Result und ResultSet[]. Übergibt man aber
einen konkreten Devicenamen als Parameter, dann enthält das Objekt nur ein
Attribut Result, das wiederum das Attribut ResultSet (diesmal kein Array)
enthält (also JSON.parse(answer).Result.ResultSet statt
JSON.parse(answer).ResultSet[0]). Eigentlich sollte hier auch eine Devspec
möglich sein, es wird aber immer nur das letzte passende Device angezeigt.

Ich habe in dem Patch die Ausgabe für den dritten Fall an die ersten beiden
angepaßt. Jetzt ist die Ausgabe aber nicht mehr mit dem alten Stand
kompatibel und ich bin mir nicht sicher, ob es vernüftigt ist, auf die
Anfrage nach einem konkreten Device mit einem Array zu antworten.

Viele Grüße
Jörg

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

rudolfkoenig

                                                   

> Ich möchte die Diskussion zu JSONP auch nochmal aufgreifen und zwei Patches
> vorschlagen:

Den FHEMWEB Patch habe ich eingecheckt.
Den anderen sollte Martin (Autor von jsonlist) uebernehmen.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

Hallo, stimme dir voll zu das CORS über eine attr aktiviert werden sollte.
Der im "Access-Control-Allow-Methods" Header muss laut spezifikation ausser
GET mindestens noch OPTIONS angegeben werden damit CORS funktioniert.
Alle modernen Browser handhaben es auch so das bei nicht gesetztem OPTIONS
die UserCredentials bei Ajax Requests nicht mitgesendet werden.
Eine Ausnahme stellt hierbei der InternetExplorer dar, dem ist das ganze
herzlich egal und man bräuchte theoretisch überhaupt keine Änderungen am
Header machen.

Am Donnerstag, 1. November 2012 09:26:46 UTC+1 schrieb Rudolf Koenig:
>
> > Hab beide diffs (EnOcean FSB61) + FHEMWEB Cors fix) nach kurzes Testen
> eingecheckt.
> > FSB61 habe ich in der commandref.html noch erwaehnt.
>
> Bin gerade ueber das CORS handling gestolpert, und ich finde, dass ein
> CORS Flag (Cross-Origin-Resource-Sharing) gehoert nicht zum Aufruf-URL
> sondern als FHEMWEB Attribut. Veto?
> Weiterhin steht in diesem Fall im header, dass FHEMWEB GET, PUT und
> OPTIONS verarbeitet: stimmt so nicht. PUT und OPTIONS habe ich erstmal
> entfernt.
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

rudolfkoenig

                                                   

> Hallo, stimme dir voll zu das CORS über eine attr aktiviert werden sollte.

Umgebaut, und eingecheckt: "attr WEB CORS 1" ist ab jetzt notwendig.


> Der im "Access-Control-Allow-Methods" Header muss laut spezifikation ausser
> GET mindestens noch OPTIONS angegeben werden damit CORS funktioniert.

Ok, OPTIONS ist wieder drin, aber auf OPTIONS antwortet FHEMWEB nicht richtig,
der kapiert nur GET :).  Kannst Du es bitte testen, ich wuesste nicht wie.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Guest

Originally posted by: <email address deleted>

Am Dienstag, 20. November 2012 18:52:02 UTC+1 schrieb Rudolf Koenig:

> Ok, OPTIONS ist wieder drin, aber auf OPTIONS antwortet FHEMWEB nicht
> richtig,
> der kapiert nur GET :).  Kannst Du es bitte testen, ich wuesste nicht wie.
>

Gerade geladen und getestet funktioniert genau so wie es soll.
Klar antwortet FHEM auf einen Options Request sogar HTTP/1.1 konform ;)
Hab das damals so angelegt das er auf einen Options Request nur mit Headern
antwortet

if($headerOptions[0]) {
>     print $c "HTTP/1.1 200 OK\r\n",
>         $FW_headercors,
>         "Content-Length: 0\r\n\r\n";
>     $hash->{BUF}="";
>     return;
>     exit(1);
> };


Funktioniert ausgezeichnet ;)

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com