Was ist der Unterschied zwischen HttpMethod und RequestType von HttpRequest?

Question

Die HttpRequest Klasse definiert zwei Eigenschaften:

HttpMethod:

Rufen die HTTP-Datenübertragungsmethode (wie GET, POST oder HEAD) vom Client verwendet.

public string HttpMethod { get; } 

Die HTTP-Datenübertragungsmethode, die vom Client verwendet wird.

und RequestType:

Ruft die HTTP-Datenübertragungsmethode (GET oder POST) durch den Client verwendet.

public string RequestType { get; set; } 

Eine Zeichenfolge, die den HTTP-Aufruftyp darstellt, der vom Client gesendet wird.

Was ist der Unterschied zwischen diesen beiden Eigenschaften? Wann möchte ich eins über dem anderen benutzen? Welches ist das Richtige, um zu sehen, welche Datenübertragungsmethode vom Kunden verwendet wurde?

Die Dokumentation zeigt an, dass Httpmethod zurückkehren wird, was Verb verwendet:

wie GET, POST oder HEAD

während die Dokumentation auf Request nur ein, um anzuzeigen, scheint von zwei möglichen Werten:

GET oder POST

---

ich mit einer Stichprobe von Verben getestet, und beide Eigenschaften scheinen alle Verben zu unterstützen, und beide geben die gleichen Werte:

Testing:

Client Used HttpMethod RequestType 
GET   GET   GET 
POST   POST   POST 
HEAD   HEAD   HEAD 
CONNECT  CONNECT  CONNECT 
MKCOL   MKCOL   MKCOL 
PUT   PUT   PUT 
FOOTEST  FOOTEST  FOOTEST 

Was ist der Unterschied zwischen:

• HttpRequest.HttpMethod
• HttpRequest.RequestType

und wann sollte ich einen über den anderen verwenden?

Answer 1

Reflector zeigt, dass RequestType intern HttpMethod ruft. Sie sind also immer so leicht besser aus rufen HttpMethod. Eigentlich glaube ich, dass der wahre Grund RequestType existiert, war für Rückwärtskompatibilität mit klassischem ASP.

Answer 2

können Sie unter Artikel überprüfen: -

anfordern Methoden: Eine HTTP-Anforderung gemacht telnet. Die Anfrage, die Antwortheader und der Antworttext sind hervorgehoben.

HTTP definiert acht Methoden (manchmal auch als "Verben" bezeichnet), die die gewünschte Aktion angeben, die an der identifizierten Ressource ausgeführt werden soll. Was diese Ressource darstellt, ob bereits vorhandene Daten oder dynamisch generierte Daten, hängt von der Implementierung des Servers ab. Oft entspricht die Ressource einer Datei oder der Ausgabe einer ausführbaren Datei, die sich auf dem Server befindet.

HEAD Fragt nach der Antwort, die identisch mit derjenigen ist, die einer GET-Anfrage entsprechen würde, aber ohne den Antworttext. Dies ist nützlich für das Abrufen von Metainformationen, die in Antwortheadern geschrieben werden, ohne dass der gesamte Inhalt übertragen werden muss.

GET Fordert eine Darstellung der angegebenen Ressource an. Beachten Sie, dass GET nicht für Operationen verwendet werden sollte, die Nebeneffekte verursachen, z. B. für Aktionen in Webanwendungen. Ein Grund dafür ist, dass GET willkürlich von Robotern oder Crawlern verwendet werden kann, die die Nebenwirkungen, die eine Anforderung verursachen sollte, nicht berücksichtigen sollten. Siehe die folgenden sicheren Methoden.

POST Sendet Daten zur Verarbeitung (z. B. aus einem HTML-Formular) an die angegebene Ressource. Die Daten sind im Hauptteil der Anfrage enthalten. Dies kann zur Erstellung einer neuen Ressource oder der Aktualisierungen vorhandener Ressourcen oder beider führen. PUT Lädt eine Darstellung der angegebenen Ressource hoch. DELETE Löscht die angegebene Ressource. TRACE Bestätigt die empfangene Anforderung, sodass ein Client sehen kann, welche zwischengeschalteten Server die Anforderung hinzufügen oder ändern. OPTIONS Gibt die HTTP-Methoden zurück, die der Server für die angegebene URL unterstützt. Dies kann verwendet werden, um die Funktionalität eines Webservers zu überprüfen, indem statt einer bestimmten Ressource '*' angefordert wird. CONNECT Konvertiert die Anforderungsverbindung in einen transparenten TCP/IP-Tunnel, um SSL-verschlüsselte Kommunikation (HTTPS) über einen unverschlüsselten HTTP-Proxy zu ermöglichen. [5] PATCH Wird verwendet, um partielle Änderungen an einer Ressource vorzunehmen. [6]

HTTP-Server sind erforderlich zumindest die GET und HEAD Methoden [7] und, wenn möglich, auch die OPTIONS-Methode zu implementieren. [Bearbeiten] Sichere Methoden

Einige Methoden (zum Beispiel, HEAD, GET , OPTIONS und TRACE) sind als sicher definiert, dh sie sind nur für den Abruf von Informationen vorgesehen und sollten den Status des Servers nicht ändern. Mit anderen Worten, sie sollten keine Nebenwirkungen haben, die über relativ harmlose Effekte wie Logging, Caching, das Ausspielen von Bannerwerbung oder das Inkrementieren eines Web Counters hinausgehen. Es sollte daher als sicher betrachtet werden, beliebige GET-Anforderungen unabhängig vom Kontext des Anwendungsstatus zu stellen.

Im Gegensatz dazu sind Methoden wie POST, PUT und DELETE für Aktionen gedacht, die Nebenwirkungen auf dem Server oder externe Nebenwirkungen wie finanzielle Transaktionen oder die Übertragung von E-Mails verursachen können. Solche Methoden werden daher normalerweise nicht von konformen Webrobotern oder Webcrawlern verwendet, die dazu neigen, Anfragen ohne Berücksichtigung von Kontext oder Konsequenzen zu stellen.

Trotz der vorgeschriebenen Sicherheit von GET-Anfragen ist in der Praxis ihre Handhabung durch den Server in keiner Weise technisch eingeschränkt und unvorsichtige oder bewusste Programmierung kann ebenso leicht (oder leichter, aufgrund fehlender Benutzeragentenvorkehrungen) verursachen nicht triviale Änderungen auf dem Server. Dies wird nicht empfohlen, da dies Probleme beim Web-Caching, bei Suchmaschinen und anderen automatisierten Agenten verursachen kann, die unbeabsichtigte Änderungen auf dem Server bewirken können.