2011-08-24 11 views
7

Mam usługi WCF REST, który ma metodę, która pobiera parametr jako ciąg znaków. Ten ciąg może zawierać ukośnik/znak. Moja prośba jest błędna, ponieważ według mnie adres URL jest nieprawidłowy.Jak przekazać ukośnik i inne znaki "wrażliwe na adres URL" do usługi REST WCF?

Podczas żądania i otrzymywania odpowiedzi (WebRequest.GetResponse()) zgłasza "Serwer zdalny zwraca błąd: (400) Błędne żądanie." wyjątek.

Moja prośba: http://localhost:17679/testmethod/DmC/TCGlOLz1EbEwqAls5Q== \ nh2cQzTizSBg =

Próbowałem użyć Uri.EscapeDataString, ale to nie pomaga, mam ten sam wyjątek jak wyżej. Po tej konwersji moja prośba wygląda następująco: http://localhost:17679/testmethod/DmC%2FTCGlOLz1EbEwqAls5Q%3D%3D%0Ah2cQzTizSBg%3D

Jeśli przekażę łańcuch bez slasha w łańcuchu, to działa tak, jak chcę.

Jak przekazać ukośnik i inne znaki "wrażliwe na adres URL" do usługi REST WCF?

Thx.

AKTUALIZACJA: Rozwiązałem, możesz to zobaczyć w mojej odpowiedzi poniżej.

+0

Dlaczego jest to niedopuszczalne? Czy nie jest dekodowane przez WCF? Jeśli tak, to co widzi twoja funkcja? Czy został zgłoszony wyjątek? Czy ustawiono metodę includeExceptionDetailInFault zgodnie z opisem w [tym dokumencie] (http://msdn.microsoft.com/en-us/library/ff649234.aspx). –

+0

Tak więc "Serwer zdalny zwrócił błąd: (400) Złe żądanie." wyjątek przychodzi podczas wywoływania metody GetResponse WebRequest. – Tom

+0

Twoje pytanie nie wyjaśniło, że podanie znaku zachęty również zwróciło błąd 400. Dokonaj edycji. –

Odpowiedz

7

Rozwiązałem to.

Szablon URI jest kluczem.

Gdybym określić URI w ten sposób, że wywołuje wyjątek powyżej:

[OperationContract()] 
    [WebGet(UriTemplate = "/testmethod/{testvalue}"/*, BodyStyle = WebMessageBodyStyle.Bare, ResponseFormat = WebMessageFormat.Xml*/)] 
    string TestMethod(string testvalue); 

Modyfikując ten sposób to działa:

[OperationContract()] 
    [WebGet(UriTemplate = "/testmethod?v={testvalue}"/*, BodyStyle = WebMessageBodyStyle.Bare, ResponseFormat = WebMessageFormat.Xml*/)] 
    string TestMethod(string testvalue); 

Zresztą Uri.EscapeDataString jest potrzebna!

-2

Spróbuj wymusić \ przed każdym /. (Normalnie zmusza metaznaki do odczytania jako normalny znak)

+0

To nie działa, to była pierwsza rzecz, którą próbowałem. Dzięki! – Tom

+0

OK, przepraszam za łatwą odpowiedź, którą próbowałem dać – Stefano

0

Chociaż zaakceptowana odpowiedź zadziała w niektórych przypadkach, gdy parametr URI znajduje się na końcu identyfikatora URI, nie zadziała, jeśli parametr URI znajduje się w środku identyfikatora URI. Jednak dzięki kilku ustawieniom konfiguracji możesz zezwolić aplikacji na akceptowanie zakodowanych ukośników w przód.

Urządzenie HttpListener, które pobiera żądania przychodzące, używa wewnętrznego obiektu HttpListenerRequestUriBuilder do analizy identyfikatora URI żądania surowego.

Kodowanie będzie kodowanie oparte na ustawieniu lub nie będzie kodowane. Dodaj następujące ustawienia do pliku app.config:

<configuration> 
    <system.net> 
    <settings> 
     <httpListener unescapeRequestUrl="false"/> 
    </settings> 
    </system.net> 
</configuration> 

Pozwoli przychodzące Message „s To nagłówki być poprawnie zbudowany bez unescaping identyfikatory URI.

Jeśli używasz wersji .NET przed 4.5, wierzę, można również dodać inne ustawienie instruowania klasę System.Uri nie ucieczki ukośniki dla http i https ścieżkach.To ustawienie jest następujący:

<configuration> 
    <uri> 
    <schemeSettings> 
     <add name="http" genericUriParserOptions="DontUnescapePathDotsAndSlashes"/> 
     <add name="https" genericUriParserOptions="DontUnescapePathDotsAndSlashes"/> 
    </schemeSettings> 
    </uri> 
</configuration> 

Uri.Match a domyślny QueryStringConverter powinny nadal pracować z tekstem przed zmianą, a więc metoda jak:

[WebGet(UriTemplate = "foos/{bar}/baz"] 
public Baz GetFooBaz(string bar) 
{ 
    // ... 
} 

zapewni Niecytowany ciąg do parametru bar.

Powiązane problemy