Hallo Robert, > Und das kann im Fehlerfall kein entsprechender anderer sein? Das **sollte** im Problemfall ein anderer sein. Man muss allerdings schauen, was der Grund für die Exception ist. Wenn am Server tatsächlich etwas gravierend schief gegangen ist, ist ein 5xx-er Status in Ordnung. Ein 4xx auch, falls der Client im Request Müll geschickt hat und die Exception deswegen flog. Wenn die Exception fachlicher Natur ist, ist ein Status 200 durchaus sinnvoll. Denn der HTTP Status meldet den technischen Erfolg des Requests, nicht den fachlichen Erfolg. Man muss dann aber die Rückgabe an den Client so gestalten, dass der Client bei Statuscode 200 (=technisch ok) zwischen "fachlich ok" und "fachlich fehlerhaft" unterscheiden kann. Wie man das gestaltet, hängt von der Natur des aufgerufenen Service ab. Was liefert er? JSON? In dem Fall kann man das JSON-Objekt so gestalten, dass es ein status-Property enthält, und damit weitermachen. Es gäbe auch noch die Möglichkeit, einen HTTP Header zu setzen. Der sollte dann mit einem "X-" beginnen, weil's ein custom header ist. Und man muss das PHP so schreiben, dass sämtliche Ausgaben gepuffert sind, damit man einen Header setzen kann. Und dann ist mit ~~~php header("X-Errorcode: $myErrorCode"); ~~~ jede Schweinerei möglich. Die Response-Header kann man in JavaScript abfragen, bei fetch über die headers-Eigenschaft der Response und bei XMLHttpRequest über die getResponseHeader Methode. Je nach Errorcode kann man festlegen, dass der gelieferte Content unterschiedliche Bedeutungen hat. FehlerTEXTE in den Headern abzulegen ginge auch, sie müssen dann aber URI-codiert werden, soweit ich weiß. Und die Länge sollte unter 8K bleiben, nicht wegen HTTP, sondern wegen des Webservers. _Rolf_ -- sumpsi - posui - obstruxi

Hallo Robert, > Und das kann im Fehlerfall kein entsprechender anderer sein? Das **sollte** im Problemfall ein anderer sein. Man muss allerdings schauen, was der Grund für die Exception ist. Wenn am Server tatsächlich etwas gravierend schief gegangen ist, ist ein 500-er Status in Ordnung. Wenn die Exception fachlicher Natur ist, ist ein Status 200 durchaus sinnvoll. Denn der HTTP Status meldet den technischen Erfolg des Requests, nicht den fachlichen Erfolg. Man muss dann aber die Rückgabe an den Client so gestalten, dass der Client bei Statuscode 200 (=technisch ok) zwischen "fachlich ok" und "fachlich fehlerhaft" unterscheiden kann. Wie man das gestaltet, hängt von der Natur des aufgerufenen Service ab. Was liefert er? JSON? In dem Fall kann man das JSON-Objekt so gestalten, dass es ein status-Property enthält, und damit weitermachen. Es gäbe auch noch die Möglichkeit, einen HTTP Header zu setzen. Der sollte dann mit einem "X-" beginnen, weil's ein custom header ist. Und man muss das PHP so schreiben, dass sämtliche Ausgaben gepuffert sind, damit man einen Header setzen kann. Und dann ist mit ~~~php header("X-Errorcode: $myErrorCode"); ~~~ jede Schweinerei möglich. Die Response-Header kann man in JavaScript abfragen, bei fetch über die headers-Eigenschaft der Response und bei XMLHttpRequest über die getResponseHeader Methode. Je nach Errorcode kann man festlegen, dass der gelieferte Content unterschiedliche Bedeutungen hat. FehlerTEXTE in den Headern abzulegen ginge auch, sie müssen dann aber URI-codiert werden, soweit ich weiß. Und die Länge sollte unter 8K bleiben, nicht wegen HTTP, sondern wegen des Webservers. _Rolf_ -- sumpsi - posui - obstruxi