JMeter 3.2 Dateiupload schlägt ASP.Net als Nulldatei

Question

Ich benutze JMeter 3.2, um meine Website zu testen. Ich habe 2 frühere Versionen benutzt, also habe ich eine Ahnung, was ich mache.

Ich teste eine ASP.NET 4.5-Site.

Wenn ich einen Datei-Upload aufzeichne, bekomme ich eine "Fehler" -Seite zurück, weil meine Anwendung die "Datei hochgeladen" -Prozedur eingibt, aber die HttpPostedFileBase ist null.

Die HTTP-Anfrage hat alles ausgefüllt, wie ich es erwarten würde.

Method: POST 
Path: the /context/controller/action as expected 
Redirect Automatically unchecked 
Follow Redirects, Use KeepAlive, Use mutipart/form-data for POST, and Browser-compatible headers checked 
The File Path has the filename (no path info) as expected 
The Parameter Name is correct 
The MIME Type is correct 

Wenn ich trennen Sie den Proxy und laden Sie die Datei, um es ganz gut funktioniert.

Wenn ich mit der Aufzeichnung aufhöre, den Listener in Simple Controller umwandeln und die aufgezeichnete Sitzung wiedergeben, kann ich sehen, dass die Seite "fail" zurückkommt. Es ist ein Antwortstatus 200, weil es eine benutzerfreundliche Fehlerseite ist, aber ich habe eine Assertion Response hinzugefügt, um den fehlgeschlagenen Status zu erfassen.

In der Ansicht Ergebnisse Baum meine Anfrage wie folgt aussieht:

POST data: 
--xr9jIAHNizYdrOAAzOIT6Yuvtp-zJlfaoDdNP 
Content-Disposition: form-data; name="notInvolvedVariableName" 

false 
--xr9jIAHNizYdrOAAzOIT6Yuvtp-zJlfaoDdNP 
Content-Disposition: form-data; name="fileUploadVariableName"; filename="JustFileName.txt" 
Content-Type: text/plain 

<actual file content, not shown here> 
--xr9jIAHNizYdrOAAzOIT6Yuvtp-zJlfaoDdNP-- 

Cookie Data: 
ASP.NET_SessionId=sessionIDblabla 

Request Headers: 
Connection: keep-alive 
Referer: THIS_STILL_HAS_HTTPS_AND_EXTERNAL_SERVER_IP_FROM_WHEN_I_RECORDED_THE_UPLOAD/UploadFile 
Accept-Language: en-US,en;q=0.5 
DNT: 1 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
Upgrade-Insecure-Requests: 1 
Accept-Encoding: gzip, deflate, br 
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0 
Content-Length: 9203 
Content-Type: multipart/form-data; boundary=xr9jIAHNizYdrOAAzOIT6Yuvtp-zJlfaoDdNP; charset=UTF-8 
Host: INTERNAL_IP 

Ich frage mich, ob durch HTTPS Aufnahme eine Rolle bei der Fehler spielt.

Ich weiß, dass meine FileServer Base auf den richtigen Ordner zeigt (durch Überprüfen der Datei jmeter.log und ich habe es getestet, indem ich den Namen in meiner HTTP-Anfrage geändert habe, was mir die IOException "Datei nicht gefunden" gab).

Ich habe den Prozess über den internen Pfad neu aufgezeichnet, um zu sehen, ob das einen Unterschied machte. Es tat es nicht. Es ist immer noch während der Aufnahme fehlgeschlagen. Die Wiedergabeanforderung zeigt den Referrer jetzt als HTTP interne IP an. Aber die Wiedergabe gibt immer noch die Fail-Seite zurück (ein Schocker, seit die Fail-Seite während der Aufnahme angezeigt wurde).

Ich sah mehrere "wie man eine Datei in JMeter" Seiten hochladen und sie alle sagen genau, was ich mache. Die meisten Seiten sagen nie, auf welche Version sie sich beziehen.

Ich legte die Debug-Ebene auf Debug und spielte es wieder zurück. In der Protokolldatei sehe ich die Header und den Dateiinhalt. Es ist in lesbarem Text, nicht base64 oder gezippt (aber ich denke, das ist in Ordnung. In Fiddler ist der Dateiinhalt auch lesbar). Der Dateiname ist wie erwartet in der Kopfzeile.

Es sieht also so aus, als ob das Protokoll alles sendet, aber es geht nicht zum Server (während der Aufnahme oder Wiedergabe). So was ist los?

Edit:

Von Fiddler in den Header:

manuell (Werke) Content-Length: 9212 Connection: Keep = lebendig

JMeter (nicht funktioniert) Content- Länge: 9188 Inhaltstyp enthält Zeichensatz = US-ASCII Verbindung: keep = alive Verbindung: Keep-Alive

Ich bin kein Experte, aber ich denke nicht, dass die extra großgeschriebene Version von Keep Alive irgendetwas beeinflusst. Ich bezweifle auch, dass die Zeichensatzspezifikation irgendetwas beeinflusst.

Der Inhalt in der TextView sieht identisch mit mir. Der Inhalt in der Raw-Ansicht enthält die Header in einer anderen Reihenfolge, aber sie sind alle im Wesentlichen identisch (mit der zusätzlichen Keep Alive in JMeter).

Inhalt Länge enthält nicht die Kopfzeile, aber der Körper sieht genau gleich anders als borderry. Die Byte-Differenz ergibt sich aus der Differenz der Boundry-Länge. Es ist 32 in JMeter und 40 manuell. Es ist 3 mal im Inhalt und addiert sich auf 24. Diese Länge ändert jeden Lauf, also denke ich, dass es nicht die Ursache sein sollte.

Also ich denke, einer Ihrer Links ist sicherlich die Ursache, weil es aussieht, als ob alles richtig sendet. Ich bin verwirrt, warum es anders aufgenommen wird, aber ich lese und sehe, wo mich das hinbringt.

Edit 2:

Ich glaube nicht, dass es eine Korrelation Problem ist.

Meine Aktion Erklärung als diese hygienisiert:

[ValidateInput(false)] 
[AcceptVerbs(HttpVerbs.Post)] 
public ActionResult UploadFile(HttpPostedFileBase myFile) 
{ 
    logger.DebugFormat("Entered UploadFile with {0}", myFile != null ? myFile.FileName : "null filename"); 
    ... 
} 

Der Protokolleintrag „Eingegebene Upload mit null Dateinamen“ sagen.

Auf der regulären GUI gibt es Javascript, das Sie daran hindert, zu senden, ohne eine Datei anzuhängen. JMeter startet js nicht, aber alles sagt mir, dass JMeter die Datei sendet.

Ich hinzugefügt, um die web.config, und das machte keinen Unterschied.

Was sonst auf IIS/ASP würde den Funktionsaufruf erlauben, aber die Datei blockieren?

Ich habe eine andere Datei hochladen, wo die Funktion keine Parameter und es greift in das Request-Objekt.

if (null != Request.Files && Request.Files.Count > 0) 
{ 
    HttpPostedFileBase hpf = Request.Files[0]; 
}//if 
else 
{ 
    logger.DebugFormat("Entered UploadFile with null filename or 0 files"); 
} 

Das auch nicht die Datei erhalten.

bearbeiten 3:

Ich habe eine Beispielanwendung, wo ich dieses Problem habe. Es protokolliert C: \ Logs.

HINWEIS: Dieser Link wird durch einen nachfolgenden Link ersetzt. http://s000.tinyupload.com/?file_id=49840904361057335433

Treffer Datei hochladen in der linken unteren Ecke. Ich habe ein Protokoll in den Reißverschluss aufgenommen.

Nur für den Fall, dass es ein FireFox-Problem war, habe ich versucht, in IE aufzunehmen und hatte das gleiche Problem. Edit 4:

Ich habe die Test-App auf einen anderen Webserver geladen (nur um sicherzustellen, dass es nicht etwas war, das der ursprüngliche Server blockierte). Ich habe dort die gleichen Ergebnisse.

Um anderen zu helfen, die Test-App oben verwenden:

So die App bauen oben (Visual Studio- 2015) angebracht.
Veröffentlichen Sie es (C: \ Logs ist, wo es bauen wird). Zip Publish_WebApp1.
Stellen Sie das auf einem Webserver bereit (ich verwende IIS 10 auf dem zweiten Server).
Versuchen Sie, einen beliebigen Dateiupload aufzuzeichnen.
Überprüfen Sie die Protokolldatei.
Versuchen Sie, eine Datei ohne den Jmeter-Proxy hochzuladen (zum Vergleich).

Bearbeiten 5: Ich lief Wireshark auf dem zweiten Server. Ich sehe einen Fehler "Server 400 Bad Request: Die Anfrage ist schlecht gebildet". Wenn ich aufnehme.

http://s000.tinyupload.com/?file_id=76890258829912351911

Und dann wird das Paket an den Pfosten zeigt sieht aus wie Müll (die markierte Stiftlänge 96). Im manuellen Lauf kann ich den Text der hochgeladenen Datei sehen (siehe den Beitrag mit der Länge 907). Ich kann diese Aufnahme aufgrund der Art der hochgeladenen Datei nicht hochladen, aber ich könnte sie mit einer gemeinsam nutzbaren Datei wiederholen, wenn jemand sie sehen möchte.

Bearbeiten 6: Ich fügte Detail zu der "post-upload" Seite in der Beispielseite hinzu.

Ich machte auch einen großen Upload mit dem Quellcode für die Beispielwebsite, die kompilierte Website und ein JMeter-Skript.

Sample Site with Code

Visual Studio 2015: im Rahmen von Projekten habe ich die WebApplication1 Quellcode

Reißverschluss

Logs: Ich habe eine Beispielprotokolldatei mit Hinweisen auf wha tthe Ergebnisse aussehen. Ich habe die gezippte IIS-ready kompilierte Website. (entpacken Sie es in inetpub und fördern Sie den Ordner zu einer App)

Temp: Hat das jmeter Skript und die Datei hochladen.

In JMeter ändern Sie Ihre HTTP-Anforderung Standard auf die IP-Adresse des Webservers Ich habe eine Verknüpfung zum Ausführen von jmeterw.cmd aus dem Ordner Temp. (Ich bin mir nicht sicher, ob das die FileServerBase antreibt oder nicht, aber meine Datei gefunden wird)

Ich bin mir immer noch nicht sicher, ob es ein JMeter Bug oder ein IIS/ASP Bug ist.

Edit 7:

Packet fängt vom Client und Server Packet Captures

Ich habe gerade bemerkt, dass die Wiedergabe "Content-Transfer-Encoding: binary", aber normal und die Aufzeichnung nicht. Das Hochladen als Binärdatei sollte in diesem Fall jedoch in Ordnung sein. Und selbst wenn der Typ falsch war, würde eine beschädigte Datei immer noch den Server treffen.

bearbeiten 8:

Die einzigen Unterschiede, die ich sehen kann, sind:

JMeter "charset = US-ASCII" auf der Content-Type fügt

JMeter fügt hinzu: „Content-Transfer-Encoding : binary“sind nur bei der Wiedergabe

JMeter Grenzen 32 Zeichen und zufällige

Manuell/Arbeitsgrenzen werden 40 Zeichen und beginnen w its viele Striche

Die Wireshark-Captures zeigen, dass JMeter-Beiträge meiner Beispieldatei immer 4 Frames sind. ungefähr 650 Bytes, 1450, 180, 38. Wo die Endgrenze im letzten Rahmen fast von selbst ist. (von allen meinen Fail Captures ist das dritte Frame immer 180, die anderen verschieben ein bisschen)

Die manuellen Posts meiner Beispieldatei sind immer 3 Frames. um 450, 1450, 370.

IMHO der Zeichensatz und Binär sollte nicht von Bedeutung sein. Ich denke nicht, dass die Anzahl der Frames zählt. Aber an dieser Stelle strebe ich nach Strohhalmen, warum das nicht funktioniert. Könnte die Grenzlänge wirklich etwas damit zu tun haben?

Answer 1

Sie haben von JMeter stammende Anfragen mit Fiddler aufgezeichnet, nehmen jetzt die gleiche Anfrage mit einem echten Browser auf und überprüfen diese beiden Anfragen, um Unterschiede festzustellen.

Die Anfragen sollten identisch sein (abgesehen von boundary und ASP.NET_SessionId), wenn sie nicht sind - Sie müssen JMeter-Konfiguration entsprechend ändern.

Meine Erwartung ist, dass Sie einige correlation als ASP.NET Web-Anwendungen weit das heißt __VIEWSTATE und __EVENTVALIDATION dynamische Parameter verwenden verpassen, und ich sehe keine Spur von ihnen.

Wenn das gleiche Szenario für die früheren JMeter-Versionen funktioniert und nicht für JMeter 3.2, kann es sich um ein Regressionsproblem handeln, das über JMeter Issue Tracker gemeldet werden muss.