Restsharp: Codierung des Leerzeichens (" ") als "%20" vs. "+"

Erstellt am 9. Juli 2018 · 7Kommentare · Quelle: restsharp/RestSharp

Erwartetes Verhalten

RestSharp codiert Leerzeichen in Formularparametern im Hauptteil als %20 , + oder gar nicht, je nach Benutzereinstellung.

Tatsächliches Verhalten

RestSharp codiert Leerzeichen in Formularparametern im Text als + .

Schritte zum Reproduzieren des Problems

Erstellen Sie eine POST-Anforderung
Fügen Sie einen Body-Schlüssel/Wert-Parameter hinzu und fügen Sie ein Leerzeichen in den Wert ein
Der resultierende HTTP-Aufruf codiert das Leerzeichen ( " " ) mit einem Pluszeichen ( "+" )

Spezifikationen

Version: 105.2.3.0
Plattform: ASP.NET-Webanwendung (.NET v4.6.2)

Quellenangabe

https://github.com/restsharp/RestSharp/blob/1805996d6f93226cdbf9dd1cc50b90423c1456c7/RestSharp/Http.cs#L322

Beschreibung

Wir rufen eine Drittanbieter-API auf, die erfordert, dass ein Parameterwert durch Leerzeichen getrennt wird (z. B. VALUE1 VALUE2 VALUE3 , codiert: param=VALUE1%20VALUE2%20VALUE3 ). Bei Verwendung von RestSharp unterscheidet sich das Verhalten von Uri.EscapeDataString() und HttpUtility.UrlEncode :

Uri.EscapeDataString("ABC DEF")
> ABC%20DEF
HttpUtility.UrlEncode("ABC DEF")
> ABC+DEF

RestSharp sollte eine gewisse Art der Anpassung in diesem Teil unterstützen oder dem Benutzer ermöglichen, seine eigene (optionale) Escape-/Codierungs-/Bereinigungsfunktion zu implementieren, um das Standardverhalten zu überschreiben.

Die HTTP-Spezifikation application/x-www-form-urlencoded erwähnt zwar, dass Leerzeichen als + codiert werden sollten, aber %20 folgt auch der Spezifikation, und nicht alle Systeme von Drittanbietern akzeptieren + als Ersatz für ein Leerzeichen unabhängig von der Spezifikation.

Hinweis: Gibt es eine Problemumgehung, um den Formulartext als param=ABC%20DEF zu codieren?

Quelle

qJake

Alle 7 Kommentare

Es wäre schön, wenn Sie auch einen Vorschlag zur Behebung dieses Problems oder eine Pull-Anfrage machen könnten.

alexeyzimarev am 18. Juli 2018

Ich bin gerade auch darauf gestoßen und habe gegen eine API verstoßen, die nur „%20“ und nicht „+“ für GET-Parameter bei einem REST-Aufruf akzeptiert, aber die Grundursache ist identisch.

Die naheliegende Lösung wäre, das Verhalten von EncodeParameter irgendwie zu überschreiben, um die Verwendung von EscapeDataString anstelle von UrlEncode zu ermöglichen

Es gibt eine Reihe ausführlicher Threads zu Stack Overflow (z. B. https://stackoverflow.com/questions/602642/server-urlencode-vs-httputility-urlencode), aber es ist letztendlich unklar, was das richtige Verhalten tatsächlich ist. . und es wäre sehr praktisch, eine Möglichkeit zu haben, das auszuwählen, was Sie brauchen, anstatt immer UrlEncode zu verwenden, was in einigen Fällen definitiv nicht das richtige Verhalten ist.

Verwenden Sie als Problemumgehung im Grunde nichts, was Parameters setzt, und führen Sie dies manuell durch.

shadowmint am 19. Juli 2018

👍1

Ich denke über den besten Weg nach, dies zu implementieren ... wahrscheinlich eine IParameterEncoder -Schnittstelle mit einem DefaultParameterEncoder , das HttpUtility.UrlEncode(...) aufruft, das als Standardimplementierung festgelegt ist, aber sein kann irgendwo überschrieben. Ist es sinnvoll, es in RestClient , oder sollte es in Http gehen, so wie hier die Eigenschaft IWebProxy ?

https://github.com/restsharp/RestSharp/blob/1805996d6f93226cdbf9dd1cc50b90423c1456c7/RestSharp/Http.cs#L220

qJake am 19. Juli 2018

Ich denke, es wäre einfacher, es so zu haben:

    public Func<string, string> Encoder { get; set; } = s => HttpUtility.UrlEncode(s);

Ich habe kein Bedürfnis nach einer Schnittstelle für eine einzelne Funktion.

alexeyzimarev am 19. Juli 2018

👍1

@qJake so
https://github.com/restsharp/RestSharp/commit/62e95bd03a0c64ac3933b648be4ee18d6c220ad7#diff -fbb0205ba27639004072c041141c4459R133

        /// <summary>
        /// Allows to use a custom way to encode parameters
        /// </summary>
        /// <param name="encoder">A delegate to encode parameters</param>
        /// <example>client.UseUrlEncoder(s => HttpUtility.UrlEncode(s));</example>
        /// <returns></returns>
        public IRestClient UseUrlEncoder(Func<string, string> encoder)
        {
            Encode = encoder;
            return this;
        }

alexeyzimarev am 18. Jan. 2019

❤1

@alexeyzimarev Ja! Das wäre großartig. 👍

qJake am 18. Jan. 2019

Wird in der nächsten Version veröffentlicht.

alexeyzimarev am 21. Jan. 2019

🎉1

War diese Seite hilfreich?

0 / 5 - 0 Bewertungen