ich musste heute feststellen, dass sich das Verhalten der REST API mit dem Update bei der Maskierung der URL Parameter grundlegend verändert hat. Bisher musste man alle URL Parameter maskieren. Seit pascom 19.17/19.18 führt dies bei Parametern mit Leer- und Sonderzeichen jedoch zu einem 500er Server-Fehler. Beispielsweise wirft “/identity/{userName}/device/{deviceName}/action” bei maskierten Sonderzeichen in {deviceName} den Fehler, dass das Gerät {deviceName} nicht gefunden wurde.
Um das Problem zu lösen, müsst ihr die URL Enkodierung der Parameter entfernen. Sprich, aus:
/identity/maxmustermann/device/pascom+Softphone+[Max+Mustermann] wird /identity/maxmustermann/device/pascom Softphone [Max Mustermann]
Es scheint, als wenn pascom das Dekodieren der URL Parameter entfernt oder verändert hätte. Bitte berücksichtigt dies bei euren Lösungen. Ich hoffe, dass pascom hier nochmal schnell Version 19.19 nachschiebt, denn nicht alle Systeme können so schnell verändert werden wie unser internes.
Es ist erlaubt das Leerzeichen als “+” zu enkodieren falls es sich um eine formencoded payload (bei einen POST) oder als Teil der Query (nach dem Fragezeichen in der URL) handelt.
Die Korrekte Enkodierung ist ein %20 für jedes Space. Dein Framework macht das vermutlich automatisch seit Du die Plus-Zeichen entfernt hast.
Wir haben im Zuge der 19.17 einige interne Frameworks auf neue Versionen gehoben bzw. optimiert. Mag gut sein das vorher die nicht-konforme Enkodierung versehentlich akzeptiert wurde.
Das Plus habe ich aus einer frühen pascom Version aus der interaktiven REST Dokumentation in der die Leerzeichen mit + maskiert wurden. %20 hatte nicht funktioniert, denn damals bekam ich den gleichen Fehler, nur eben mit %20 als Fehlerursache. Ich weiß nur nicht mehr, ob das schon pascom 19 oder noch 18 war. In der jetzigen interaktiven REST Dokumentation werden Leerzeichen gar nicht maskiert.
RFC 3986 section 2.2 Reserved Characters (January 2005)
[…]+[…]
Other characters in a URI must be percent encoded.
Das Plus ist durchaus ein standardkonformes Zeichen für Leerzeichen in URLs, wenngleich die Prozent-Maskierung von Leerzeichen nach RFC 3986 empfohlen wird und das Plus heutzutage nahezu ausschließlich bei application/x-www-form-urlencoded Formularen verwendet wird. Dennoch ist es im URL-Pfad nicht grundsätzlich invalide. In Query-Parametern hingegen definitiv nicht erlaubt.
ich würde mich hier gerne anhängen, seit dem letzten Update habe ich Probleme mit Anfragen an die API wenn das Sonderzeichen # involviert ist.
Genauer haben wir einige Devices, die ein # im Feld 010dev_bez haben, zB “Aastra-Mitel GqizpOk4m564962 [#Steuerbord]”. Wenn ich für solch ein Gerät eine API Abfrage an /device/ schicke wird das # Zeichen korrekt zu %23 encodiert, aber die Anfrage bleibt trotzdem unbeantwortet.
Das gleiche passiert mir, wenn ich über die “Entwicklerwebsite” die interactive Demo der API verwende. Auch da wird korrekt zu %23 encoded, aber ich bekomme trotzdem nicht die Device Infos zuürck.