[vz-dev] JSONP exception handling
Hallo Zusammen, wenn in der MW eine Exception auftritt wird diese vom JSON view an den Aufrufer zurückgesandt (z.B. "invalid uuid"). Bei JSONP funktioniert das nicht, weil bei HTTP Response Code 400 das JSONP Skript von remote gar nicht erst ausgeführt wird. Einen RFC für JSONP konnte ich nicht finden, daher meine Frage bevor ich einen Patch bereitstelle: sollten wir bei JSONP nicht _immer_ HTTP 200 OK zurückgeben statt 400 oder sonstiger Codes? Das Frontend wäre von dieser Änderung nicht betroffen- hier werden Exceptions auch bei HTTP 200 sauber behandelt soweit ich den Code gesehen habe. +1 für den Patch von mir- was meint Ihr? vg Andreas PS.: ich würde dann auch gerne- zusammen mit den sonstigen Änderungen- die MW Version auf 0.3 erhöhen und die entsprechende Doku im Wiki anpassen.
Re: [vz-dev] JSONP exception handling
Servus, Eine gnereller Responsecode von 200 widerspricht aber grob REST-Paradigmen. Besser man wechselt auf CORS-Header Webserverseitig, dann benötigt es kein JSONP mehr. Am 26.09.2013 13:33 schrieb "Andreas Goetz" : > Hallo Zusammen, > > wenn in der MW eine Exception auftritt wird diese vom JSON view an den > Aufrufer zurückgesandt (z.B. "invalid uuid"). > Bei JSONP funktioniert das nicht, weil bei HTTP Response Code 400 das > JSONP Skript von remote gar nicht erst ausgeführt wird. > > Einen RFC für JSONP konnte ich nicht finden, daher meine Frage bevor ich > einen Patch bereitstelle: sollten wir bei JSONP nicht _immer_ HTTP 200 OK > zurückgeben statt 400 oder sonstiger Codes? > > Das Frontend wäre von dieser Änderung nicht betroffen- hier werden > Exceptions auch bei HTTP 200 sauber behandelt soweit ich den Code gesehen > habe. > > +1 für den Patch von mir- was meint Ihr? > > vg > Andreas > > PS.: ich würde dann auch gerne- zusammen mit den sonstigen Änderungen- die > MW Version auf 0.3 erhöhen und die entsprechende Doku im Wiki anpassen. > >
Re: [vz-dev] JSONP exception handling
Hallo Patrick, das kann alles sein. Da wir Clients mit JSON(P) haben würde ich jetzt aber gerne erstmal das Problem lösen. CORS zusätzlich zu implementieren ist eine nette Aufgabe die ich ebenfalls übernehmen würde. vg Andreas 2013/9/26 Patrik Karisch > Servus, > > Eine gnereller Responsecode von 200 widerspricht aber grob > REST-Paradigmen. Besser man wechselt auf CORS-Header Webserverseitig, dann > benötigt es kein JSONP mehr. > Am 26.09.2013 13:33 schrieb "Andreas Goetz" : > > Hallo Zusammen, >> >> wenn in der MW eine Exception auftritt wird diese vom JSON view an den >> Aufrufer zurückgesandt (z.B. "invalid uuid"). >> Bei JSONP funktioniert das nicht, weil bei HTTP Response Code 400 das >> JSONP Skript von remote gar nicht erst ausgeführt wird. >> >> Einen RFC für JSONP konnte ich nicht finden, daher meine Frage bevor ich >> einen Patch bereitstelle: sollten wir bei JSONP nicht _immer_ HTTP 200 OK >> zurückgeben statt 400 oder sonstiger Codes? >> >> Das Frontend wäre von dieser Änderung nicht betroffen- hier werden >> Exceptions auch bei HTTP 200 sauber behandelt soweit ich den Code gesehen >> habe. >> >> +1 für den Patch von mir- was meint Ihr? >> >> vg >> Andreas >> >> PS.: ich würde dann auch gerne- zusammen mit den sonstigen Änderungen- >> die MW Version auf 0.3 erhöhen und die entsprechende Doku im Wiki anpassen. >> >>
Re: [vz-dev] JSONP exception handling
CORS ist mit einer .htaccess sofort aktiviert: Header set Access-Control-Allow-Origin "*" JS-seitig muss nur herausgenommen werden, das JSONP verwendet wird. Ansonsten ist das Handling wie beim normalen JSON über die selbe Domain. Kein Unterschied. Höchstens Serverseitig muss man noch eine OPTIONS Anfrage korrekt handlen, sollten PUT und DELETE-Requests oder POSTs mit nicht x-www-urlencoded Daten. Da wird vom Browser ein "Pre-Flight" ausgeführt. Siehe https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS#Preflighted_requests Ansichtssache, aber beides dürfte auf die selbe Schreiberei hinauslaufen.. lg Am 26. September 2013 16:44 schrieb Andreas Goetz : > Hallo Patrick, > > das kann alles sein. Da wir Clients mit JSON(P) haben würde ich jetzt aber > gerne erstmal das Problem lösen. CORS zusätzlich zu implementieren ist eine > nette Aufgabe die ich ebenfalls übernehmen würde. > > vg > Andreas > > > > 2013/9/26 Patrik Karisch >> >> Servus, >> >> Eine gnereller Responsecode von 200 widerspricht aber grob >> REST-Paradigmen. Besser man wechselt auf CORS-Header Webserverseitig, dann >> benötigt es kein JSONP mehr. >> >> Am 26.09.2013 13:33 schrieb "Andreas Goetz" : >> >>> Hallo Zusammen, >>> >>> wenn in der MW eine Exception auftritt wird diese vom JSON view an den >>> Aufrufer zurückgesandt (z.B. "invalid uuid"). >>> Bei JSONP funktioniert das nicht, weil bei HTTP Response Code 400 das >>> JSONP Skript von remote gar nicht erst ausgeführt wird. >>> >>> Einen RFC für JSONP konnte ich nicht finden, daher meine Frage bevor ich >>> einen Patch bereitstelle: sollten wir bei JSONP nicht _immer_ HTTP 200 OK >>> zurückgeben statt 400 oder sonstiger Codes? >>> >>> Das Frontend wäre von dieser Änderung nicht betroffen- hier werden >>> Exceptions auch bei HTTP 200 sauber behandelt soweit ich den Code gesehen >>> habe. >>> >>> +1 für den Patch von mir- was meint Ihr? >>> >>> vg >>> Andreas >>> >>> PS.: ich würde dann auch gerne- zusammen mit den sonstigen Änderungen- >>> die MW Version auf 0.3 erhöhen und die entsprechende Doku im Wiki anpassen. >>> > -- mit freundlichen Grüßen // best regards Patrik Karisch
Re: [vz-dev] JSONP exception handling
On Thu, 26 Sep 2013 16:26:19 +0200 Patrik Karisch wrote: > Eine gnereller Responsecode von 200 widerspricht aber grob > REST-Paradigmen. Besser man wechselt auf CORS-Header Webserverseitig, > dann benötigt es kein JSONP mehr. OK, wir bekommen dann also zwei patches, einen von Andreas um bei jsonp fehlermeldungen als 200/OK auszuliefern, einen von Patrick fuer das viel elegantere CORS; desweiteren bringt Patrick allen unseren (l)usern bei, ihren webserver entsprechend zu konfigurieren, und kuemmert sich um alle anfallenden support-anfragen diesbezueglich. - Thorben > Am 26.09.2013 13:33 schrieb "Andreas Goetz" : > > > Hallo Zusammen, > > > > wenn in der MW eine Exception auftritt wird diese vom JSON view an > > den Aufrufer zurückgesandt (z.B. "invalid uuid"). > > Bei JSONP funktioniert das nicht, weil bei HTTP Response Code 400 > > das JSONP Skript von remote gar nicht erst ausgeführt wird. > > > > Einen RFC für JSONP konnte ich nicht finden, daher meine Frage > > bevor ich einen Patch bereitstelle: sollten wir bei JSONP nicht > > _immer_ HTTP 200 OK zurückgeben statt 400 oder sonstiger Codes? > > > > Das Frontend wäre von dieser Änderung nicht betroffen- hier werden > > Exceptions auch bei HTTP 200 sauber behandelt soweit ich den Code > > gesehen habe. > > > > +1 für den Patch von mir- was meint Ihr? > > > > vg > > Andreas > > > > PS.: ich würde dann auch gerne- zusammen mit den sonstigen > > Änderungen- die MW Version auf 0.3 erhöhen und die entsprechende > > Doku im Wiki anpassen. > > > >
Re: [vz-dev] JSONP exception handling
Moin, das ging tatsächlich verblüffend einfach- deshalb hab ich mir die Freiheit genommen die 5 geänderten Teilen in einen Pullrequest zu packen: The following changes since commit 1670af32d3986887f754ad785628b003243cf3cf: Fix JSONP exception handling and add CORS support Also fixed an artifact in AggregatorInterpreter (2013-09-26 20:42:29 +0200) are available in the git repository at: htto://github.com/volkszaehler/volkszaehler.org for you to fetch changes up to 1670af32d3986887f754ad785628b003243cf3cf: Fix JSONP exception handling and add CORS support Also fixed an artifact in AggregatorInterpreter (2013-09-26 20:42:29 +0200) Wie siehts denn mit VZ_VERSION aus- wollen wir auf 0.3 gehen? Damit könnte ich das Dokuupdate im Wiki sauber einem Releasestand zuordnen? vg Andreas 2013/9/26 Thorben Thuermer > On Thu, 26 Sep 2013 16:26:19 +0200 > Patrik Karisch wrote: > > Eine gnereller Responsecode von 200 widerspricht aber grob > > REST-Paradigmen. Besser man wechselt auf CORS-Header Webserverseitig, > > dann benötigt es kein JSONP mehr. > > OK, > wir bekommen dann also zwei patches, > einen von Andreas um bei jsonp fehlermeldungen als 200/OK auszuliefern, > einen von Patrick fuer das viel elegantere CORS; > desweiteren bringt Patrick allen unseren (l)usern bei, > ihren webserver entsprechend zu konfigurieren, und kuemmert sich um > alle anfallenden support-anfragen diesbezueglich. > > - Thorben > > > Am 26.09.2013 13:33 schrieb "Andreas Goetz" : > > > > > Hallo Zusammen, > > > > > > wenn in der MW eine Exception auftritt wird diese vom JSON view an > > > den Aufrufer zurückgesandt (z.B. "invalid uuid"). > > > Bei JSONP funktioniert das nicht, weil bei HTTP Response Code 400 > > > das JSONP Skript von remote gar nicht erst ausgeführt wird. > > > > > > Einen RFC für JSONP konnte ich nicht finden, daher meine Frage > > > bevor ich einen Patch bereitstelle: sollten wir bei JSONP nicht > > > _immer_ HTTP 200 OK zurückgeben statt 400 oder sonstiger Codes? > > > > > > Das Frontend wäre von dieser Änderung nicht betroffen- hier werden > > > Exceptions auch bei HTTP 200 sauber behandelt soweit ich den Code > > > gesehen habe. > > > > > > +1 für den Patch von mir- was meint Ihr? > > > > > > vg > > > Andreas > > > > > > PS.: ich würde dann auch gerne- zusammen mit den sonstigen > > > Änderungen- die MW Version auf 0.3 erhöhen und die entsprechende > > > Doku im Wiki anpassen. > > > > > > > >
Re: [vz-dev] JSONP exception handling
On Thu, 26 Sep 2013 20:44:41 +0200 Andreas Goetz wrote: > das ging tatsächlich verblüffend einfach- deshalb hab ich mir die Freiheit > genommen die 5 geänderten Teilen in einen Pullrequest zu packen: ist ja eh voellig unkritisch, zumal das frontend damit weiterhin jsonp verwendet. (ist gemerged) > Wie siehts denn mit VZ_VERSION aus- wollen wir auf 0.3 gehen? Damit könnte > ich das Dokuupdate im Wiki sauber einem Releasestand zuordnen? habe ich ueberhaupt kein problem mit, und ich denke auch niemand sonst, also mach' einfach... wobei ich nicht ganz einschaetzen kann, wie stabil die api ueberhaupt ist (es gab iirc schon andere aenderungen im verhalten und den rueckgaben), und eher in der doku anmerken wuerde, seit welcher revision ein bestimmtes feature/verhalten vorhanden ist. die doku fuer die alte version duerfte eh kaum mehr jemanden interessieren. > vg > Andreas - Thorben > 2013/9/26 Thorben Thuermer > > > On Thu, 26 Sep 2013 16:26:19 +0200 > > Patrik Karisch wrote: > > > Eine gnereller Responsecode von 200 widerspricht aber grob > > > REST-Paradigmen. Besser man wechselt auf CORS-Header Webserverseitig, > > > dann benötigt es kein JSONP mehr. > > > > OK, > > wir bekommen dann also zwei patches, > > einen von Andreas um bei jsonp fehlermeldungen als 200/OK auszuliefern, > > einen von Patrick fuer das viel elegantere CORS; > > desweiteren bringt Patrick allen unseren (l)usern bei, > > ihren webserver entsprechend zu konfigurieren, und kuemmert sich um > > alle anfallenden support-anfragen diesbezueglich. > > > > - Thorben > > > > > Am 26.09.2013 13:33 schrieb "Andreas Goetz" : > > > > > > > Hallo Zusammen, > > > > > > > > wenn in der MW eine Exception auftritt wird diese vom JSON view an > > > > den Aufrufer zurückgesandt (z.B. "invalid uuid"). > > > > Bei JSONP funktioniert das nicht, weil bei HTTP Response Code 400 > > > > das JSONP Skript von remote gar nicht erst ausgeführt wird. > > > > > > > > Einen RFC für JSONP konnte ich nicht finden, daher meine Frage > > > > bevor ich einen Patch bereitstelle: sollten wir bei JSONP nicht > > > > _immer_ HTTP 200 OK zurückgeben statt 400 oder sonstiger Codes? > > > > > > > > Das Frontend wäre von dieser Änderung nicht betroffen- hier werden > > > > Exceptions auch bei HTTP 200 sauber behandelt soweit ich den Code > > > > gesehen habe. > > > > > > > > +1 für den Patch von mir- was meint Ihr? > > > > > > > > vg > > > > Andreas > > > > > > > > PS.: ich würde dann auch gerne- zusammen mit den sonstigen > > > > Änderungen- die MW Version auf 0.3 erhöhen und die entsprechende > > > > Doku im Wiki anpassen. > > > > > > > > > > > >
