Ist wirklich QueryString groß-und Kleinschreibung?
Arbeite ich an einer payment-Plattform, und, in Reaktion auf eine Zahlung, eine einfache GET-Aufruf, mit dem einige Parameter im query-string, ist aus meiner Hörer:
http://localhost/mytest/listener?TIMECREATED=04.08.2015+12%3A22%3A27&statoattuale=OK&PREVIOUSSTATE=IN&CURRENTSTATE=payment_approved&tipomessaggio=PAYMENT_STATE&DESCRIZIONE=CAMBIO+DI+STATO&datacreazione=04.08.2015+12%3A22%3A27&stabilimento=xxxxxx&MerchantNumber=xxxxxx&descrizione=CAMBIO+DI+STATO&OBJECT=PAYMENT&TIMEGENERATED=04.08.2015+12%3A23%3A17&MERCHANTNUMBER=xxxxxx&statoprecedente=IN&MERCHANTACCOUNT=xxxxxx&numeroOrdine=myOrderNo&numeroCommerciante=xxxxxx&datagenerazione=04.08.2015+12%3A23%3A17&ORDERNUMBER=myOrderNo&Stabilimento=xxxxxx&mac=CaWJiRCxbWH%2FsNFMvHUD2A%3D%3D&MAC=AnsEvRHkvMwRL%2FgehVtnhA%3D%3D
Wenn ich überprüfen Request.QueryString
was ich sehe, ist ein Durcheinander von param-Bestellung und Fall. Scheint, wie Sie werden neu geordnet mit angepassten Fall für das erste auftauchen. Wie diese:
TIMECREATED=04.08.2015
12:22:27&statoattuale=OK&PREVIOUSSTATE=IN&CURRENTSTATE=payment_approved&tipomessaggio=PAYMENT_STATE&DESCRIZIONE=CAMBIO
DI STATO&DESCRIZIONE=CAMBIO DI STATO&datacreazione=04.08.2015
12:22:27&stabilimento=xxxxxx&stabilimento=xxxxxx&MerchantNumber=xxxxxx&MerchantNumber=xxxxxx&OBJECT=PAYMENT&TIMEGENERATED=04.08.2015
12:23:17&statoprecedente=IN&MERCHANTACCOUNT=999988801&numeroOrdine=myOrderNo&numeroCommerciante=xxxxxx&datagenerazione=04.08.2015
12:23:17&ORDERNUMBER=myOrderNo&mac=CaWJiRCxbWH/sNFMvHUD2A==&mac=AnsEvRHkvMwRL/gehVtnhA==
Für mich sieht es aus wie ein bug, denn die RFC3986 Staaten:
Wenn ein URI verwendet Komponenten des generic syntax, die Komponente
syntax äquivalenz-Regeln, die immer gelten; nämlich, dass die Regelung und
Gastgeber sind der groß-und Kleinschreibung und sollte daher normiert werden, um
Kleinbuchstaben. Zum Beispiel wird der URI
entspricht http://www.example.com/. Der anderen generic syntax
Komponenten sind davon ausgegangen, dass groß-und Kleinschreibung, sofern Sie nicht speziell
anders definiert durch das Schema (siehe Abschnitt 6.2.3).
Im moment habe ich mein problem gelöst, indem Sie manuell analysieren Url.Query
, aber ich glaube nicht, dass wie Verhalten sich die Anfrage.QueryString richtig ist.
Kann jemand etwas Licht in die Angelegenheit bringen?
- Was genau ist deine Frage/problem?
Request.QueryString
ist nicht case sensitive. Sie könnenRequest.QueryString["test"]
oderRequest.QueryString["TEST"]
und beide bekommen die gleichen parameter Wert - Das ist mein Punkt. Wenn Sie versuchen, zu tun
Request.QueryString["mac"]
erhalten SieCaWJiRCxbWH/sNFMvHUD2A==,AnsEvRHkvMwRL/gehVtnhA==
(beide Werte durch ein Komma getrennt) auch fürRequest.QueryString["MAC"]
undRequest.QueryString["mAc"]
Sie erhalten das gleiche Ergebnis. Und auch, warumRequest.QueryString
fühlen sich die Notwendigkeit, die Reihenfolge zu ändern, und der Fall der params? - RFC sagen, dass params betrachtet werden muss, der groß-und Kleinschreibung. Also, warum es nicht respektieren?
- Der RFC ist in Ordnung. .Netto-Einrichtungen, mit denen Sie interagieren sind eine ganz andere Sache. Wenn Sie eine strikt Kleinschreibung Ansatz, dann müssen Sie tun, was Sie getan haben.
- Für den Fall, jemand kommt hierher, weil Sie sich Wundern, wenn
HttpContext.Request.Query["foo"]
ist der groß-und Kleinschreibung, es bezieht sich auf die gleiche Sache und daher, ja, es ist auch.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Leider ist die API nicht bieten einen Weg, um das
Request.QueryString
collection groß - /Kleinschreibung (oder dieRequest.Headers
oderRequest.Form
Sammlungen, für diese Angelegenheit).Jedoch, mit ein bisschen reverse engineering, über die Reflexion, es ist nicht so schwer zu tun.
Nutzung
Wenn Sie ein querystring-wie
?MAC=123&mac=456
können Sie sehen, Sie werden separat gehalten.