nicht angemeldet
MudGuard
Der Martin
dedlfix
Der Martin
Der Martin
Der Martin
Tabellenkalk
Tabellenkalk
Wenn ein Webserver entsprechend konfiguriert ist, hält er bei einer Anfrage (Request) mit dem Header Connection: Keep-Alive die Verbindung (Socket) offen und sendet mehrere Antwortseiten in einer einzigen Datei. Jede in dieser Datei steckende Antwortseite ist in sich komplett, enthält also alle Response-Header und den Message Body. Die einzelnen Responses mit ggf. verschiedenen Content-Type sind aneinandergehängt und ein Browser kriegt die wieder auseinander.
Auf der Suche nach anderen Programmen die das auch können, wärs gut zu wissen, wie der Content-Type heißt. Vorschläge?
Hi,
Wenn ein Webserver entsprechend konfiguriert ist, hält er bei einer Anfrage (Request) mit dem Header Connection: Keep-Alive die Verbindung (Socket) offen und sendet mehrere Antwortseiten in einer einzigen Datei.
Ist das so?
Ich hätte gedacht, die Verbindung wird nach Request/Response nicht abgebaut, so daß der nächste Request samt Response auf der gleichen Verbindung stattfindet.
Aber jedes Pärchen aus Request und Response unabhängig von den anderen.
cu,
Andreas a/k/a MudGuard
Hi,
Wenn ein Webserver entsprechend konfiguriert ist, hält er bei einer Anfrage (Request) mit dem Header Connection: Keep-Alive die Verbindung (Socket) offen und sendet mehrere Antwortseiten in einer einzigen Datei.
Ist das so?
Ja, ab HTTP/1.1 Mit entsprechenden Entwicklertools durchaus nachvollziehbar. Aber ich fürchte der Content-Type hat gar keinen Namen ;)
Moin,
Wenn ein Webserver entsprechend konfiguriert ist, hält er bei einer Anfrage (Request) mit dem Header Connection: Keep-Alive die Verbindung (Socket) offen und sendet mehrere Antwortseiten in einer einzigen Datei.
Ist das so?
nein, nicht ganz. Der Server sendet eine Ressource und empfängt einen Folge-Request über dieselbe Socket-Verbindung. Aber zusammengefasst wird da nichts.
Ich hätte gedacht, die Verbindung wird nach Request/Response nicht abgebaut, so daß der nächste Request samt Response auf der gleichen Verbindung stattfindet.
Aber jedes Pärchen aus Request und Response unabhängig von den anderen.
Exakt. Aus HTTP-Sicht ist das also nichts Neues. Es gibt kein übergeordnetes Container-Protokoll oder gar einen eigenen Content-Type dafür. Der Unterschied zum One-By-One-Transfer liegt nur in der TCP-Schicht und im HTTP-Header Connection: Keep-Alive bzw. Connection: Close im Request, mit dem dieses Verhalten gesteuert wird.
So long,
Martin
Hi,
Wenn ein Webserver entsprechend konfiguriert ist, hält er bei einer Anfrage (Request) mit dem Header Connection: Keep-Alive die Verbindung (Socket) offen und sendet mehrere Antwortseiten in einer einzigen Datei.
Ist das so?
Ich hätte gedacht, die Verbindung wird nach Request/Response nicht abgebaut, so daß der nächste Request samt Response auf der gleichen Verbindung stattfindet.
Aber jedes Pärchen aus Request und Response unabhängig von den anderen.
Btw., versuche mal, das so zu programmieren. Du kommst dann an einen Punkt, wo der Server in das Socket lauscht ob weiterer Requests (offene Verbindung). Gleichzeitig lauscht der Client in das Socket ob einer Response.
Und wennse nicht gestorben sind, warten die noch heute ;)
Ich hoffe, Dir ist klar, dass das so gar nicht gehen kann. Und wenn Du das mal selber programmieren tätest, kämest Du recht schnell dahinter, dass es so ist, wie ich das hier schreibe.
Tach!
Btw., versuche mal, das so zu programmieren. Du kommst dann an einen Punkt, wo der Server in das Socket lauscht ob weiterer Requests (offene Verbindung). Gleichzeitig lauscht der Client in das Socket ob einer Response.
Warum sollte der Client weiter lauschen, wenn er fertig ist mit seinen Anfragen? Der Letzte macht das Licht aus. Wenn alle eingebundenen und nicht aus dem Cache bedienbaren Ressourcen abgefragt wurden, muss der Client die Verbindung nicht mehr offenhalten und er kann den letzten Request mit Connection: Close schicken.
Und wennse nicht gestorben sind, warten die noch heute ;)
TCP/IP-Verbindungn haben auch noch ein Timeout. Da kappt spätestens das Betriebssystem (sprich: der TCP/IP-Stack) die Verbindung, wenn darüber nichts mehr läuft.
dedlfix.
Tach!
Btw., versuche mal, das so zu programmieren. Du kommst dann an einen Punkt, wo der Server in das Socket lauscht ob weiterer Requests (offene Verbindung). Gleichzeitig lauscht der Client in das Socket ob einer Response.
Warum sollte der Client weiter lauschen, wenn er fertig ist mit seinen Anfragen?
Richtig. Deswegen macht das ja auch keiner.
TCP/IP-Verbindungn haben auch noch ein Timeout. Da kappt spätestens das Betriebssystem (sprich: der TCP/IP-Stack) die Verbindung, wenn darüber nichts mehr läuft.
Ach was. Ich hätt' wetten können....
Hallo pl,
Btw., versuche mal, das so zu programmieren. Du kommst dann an einen Punkt, wo der Server in das Socket lauscht ob weiterer Requests (offene Verbindung). Gleichzeitig lauscht der Client in das Socket ob einer Response.
Dann hast du den Response falsch zusammen gebaut. Für Verbindungen mit Connection: keep-alive musst du entweder Transfer-Encoding: chunked angeben oder eine Content-Length angeben, denn sonst weiss der Client nicht, wann der Response vorbei ist.
Ich hoffe, Dir ist klar, dass das so gar nicht gehen kann. Und wenn Du das mal selber programmieren tätest, kämest Du recht schnell dahinter, dass es so ist, wie ich das hier schreibe.
Nein. Mudguard hat recht. Erst mit HTTP/2 wird das deutlich komplexer, Stichwort Multiplexing.
Das einzige, was sowohl Martin als auch Mudguard nicht erwähnt haben ist Pipelining. Die Browser senden mehrere Requests direkt hintereinander ohne auf die Antwort zu warten, und der Server antwortet in der Reihenfolge in der die Requests eingingen. Das ist aber nicht der von dir beschriebene Mechanismus.
LG,
CK
Das einzige, was sowohl Martin als auch Mudguard nicht erwähnt haben ist Pipelining. Die Browser senden mehrere Requests direkt hintereinander ohne auf die Antwort zu warten, und der Server antwortet in der Reihenfolge in der die Requests eingingen. Das ist aber nicht der von dir beschriebene Mechanismus.
Doch, das ist genau das, was ich beschrieben habe. Falls ihr das immer noch nicht verstanden habt: Der Server schickt alles zusammen in einer Antwort. Wie heißt denn nun der Content-Type?
Hallo pl,
Doch, das ist genau das, was ich beschrieben habe.
Nein. Ich zitiere dich:
Wenn ein Webserver entsprechend konfiguriert ist, hält er bei einer Anfrage (Request) mit dem Header Connection: Keep-Alive die Verbindung (Socket) offen und sendet mehrere Antwortseiten in einer einzigen Datei.
Das ist etwas völlig anderes.
Falls ihr das immer noch nicht verstanden habt: Der Server schickt alles zusammen in einer Antwort.
Das ist etwas anderes als du beschrieben hast.
Wie heißt denn nun der Content-Type?
Es gibt keinen. Ich habe dir den Mechanismus beschrieben, das hat nichts mit Content-Type zu tun.
LG,
CK
Hi,
Das einzige, was sowohl Martin als auch Mudguard nicht erwähnt haben ist Pipelining. Die Browser senden mehrere Requests direkt hintereinander ohne auf die Antwort zu warten, und der Server antwortet in der Reihenfolge in der die Requests eingingen. Das ist aber nicht der von dir beschriebene Mechanismus.
das geht dann aber AFAIK über mehrere getrennte Sockets, oder? Das heißt, jede Verbindung für sich eine streng sequentielle Geschichte. Denn andernfalls wäre die Zuordnung ja nicht mehr eindeutig möglich.
Aus der Ecke kommt IIRC auch die Empfehlung aus der HTTP-Spec, dass ein Client bitte nicht mehr als 8 gleichzeitige Verbindungen zu einem Server haben möge.
So long,
Martin
Hallo Martin,
Das einzige, was sowohl Martin als auch Mudguard nicht erwähnt haben ist Pipelining. Die Browser senden mehrere Requests direkt hintereinander ohne auf die Antwort zu warten, und der Server antwortet in der Reihenfolge in der die Requests eingingen. Das ist aber nicht der von dir beschriebene Mechanismus.
das geht dann aber AFAIK über mehrere getrennte Sockets, oder?
Nein. Ein Socket, mehrere Requests werden direkt hintereinander gesendet ohne auf die Antwort zu warten.
Das heißt, jede Verbindung für sich eine streng sequentielle Geschichte.
Das gilt weiterhin, die Responses der Antworten entspricht der Reihenfolge der Requests.
Aus der Ecke kommt IIRC auch die Empfehlung aus der HTTP-Spec, dass ein Client bitte nicht mehr als 8 gleichzeitige Verbindungen zu einem Server haben möge.
Andere Baustelle.
LG,
CK
Hallo Christian,
ein weiterer Mechanismus sind server-sent events. Da wäre der Content-Type dann text/event-stream. Aber ich vermute mal nicht, dass du das meinst.
LG,
CK
Hallo,
Ich hätte gedacht, die Verbindung wird nach Request/Response nicht abgebaut, so daß der nächste Request samt Response auf der gleichen Verbindung stattfindet.
Aber jedes Pärchen aus Request und Response unabhängig von den anderen.
Btw., versuche mal, das so zu programmieren. Du kommst dann an einen Punkt, wo der Server in das Socket lauscht ob weiterer Requests (offene Verbindung). Gleichzeitig lauscht der Client in das Socket ob einer Response.
nein, wieso das? Der Server verarbeitet den Request, sendet seine Response und erinnert sich dann an das Keep-Alive des Requests, hält also die Verbindung offen und lauscht weiter. So weit richtig.
Der Client dagegen hat zu der Zeit seine Antwort schon erhalten und sendet einen Augenblick später einfach seine nächste Anforderung. Danach lauscht er natürlich wieder auf Antwort.
Das Spielchen läuft so lange, bis entweder ein Request mit dem Header Connection: Close eintrifft (oder ohne den Connection-Header, denn AFAIK ist "Close" das Default-Verhalten) oder irgendein Timeout zuschlägt.
Ich hoffe, Dir ist klar, dass das so gar nicht gehen kann.
Es kann, und es tut. Und es ist sehr einfach nachzuprogrammieren - wenn man die Implementierung eines HTTP1.1-Clients insgesamt als einfach betrachtet.
So long,
Martin
Es kann, und es tut. Und es ist sehr einfach nachzuprogrammieren - wenn man die Implementierung eines HTTP1.1-Clients insgesamt als einfach betrachtet.
Na, dann mach das doch mal endlich, programmiere das so und melde Dich danach hier wieder. Ansonsten ist das wenig hilfreich was Du hier postest. Nochmal: Ich suche nur den Namen für einen Content-Type. Von dem ich übrigens sehr genau weiß wie der beschaffen ist und so geparst werden muss, dass die einzelnen Parts bytegenau wiederhergestellt werden.
Hi,
Es kann, und es tut. Und es ist sehr einfach nachzuprogrammieren - wenn man die Implementierung eines HTTP1.1-Clients insgesamt als einfach betrachtet.
Na, dann mach das doch mal endlich, programmiere das so und melde Dich danach hier wieder.
warum ich? Wollte ich etwa einen eigenen HTTP-Client haben? Nö.
Außerdem wurde die prinzipielle Funktionsweise in Worten schon sowohl von mir, als auch von Christian beschrieben.
Ansonsten ist das wenig hilfreich was Du hier postest. Nochmal: Ich suche nur den Namen für einen Content-Type. Von dem ich übrigens sehr genau weiß wie der beschaffen ist und so geparst werden muss, dass die einzelnen Parts bytegenau wiederhergestellt werden.
Möglicherweise hast du multipart/* im Sinn (multipart/alternative, multipart/mixed, multipart/related). Die haben aber in HTTP nichts verloren, sondern nur in der Gliederung von e-Mail-Anhängen.
Ciao,
Martin
Hallo,
warum ich?
na, weil hier doch neuerdings my-hammer.de hängt...
Gruß
Kalk
Hi,
Es kann, und es tut. Und es ist sehr einfach nachzuprogrammieren - wenn man die Implementierung eines HTTP1.1-Clients insgesamt als einfach betrachtet.
Na, dann mach das doch mal endlich, programmiere das so und melde Dich danach hier wieder.
warum ich? Wollte ich etwa einen eigenen HTTP-Client haben? Nö.
Außerdem wurde die prinzipielle Funktionsweise in Worten schon sowohl von mir, als auch von Christian beschrieben.
Deine und die anderen Beschreibungen sind falsch. Das kannst Du mit geigneten Entwicklerwerkzeugen nachprüfen, u.a. auch mit wireshark.
Hallo,
Deine und die anderen Beschreibungen sind falsch.
natürlich, wir liegen alle falsch. Du hast als einziger den Durchblick.
Das kannst Du mit geigneten Entwicklerwerkzeugen nachprüfen, u.a. auch mit wireshark.
Ja. Du hast recht, und wir unsere Ruhe.
Amen,
Martin
Ich hätte gedacht, die Verbindung wird nach Request/Response nicht abgebaut, so daß der nächste Request samt Response auf der gleichen Verbindung stattfindet.
Aber jedes Pärchen aus Request und Response unabhängig von den anderen.
Jop, das deckt sich mit dem, was der Standard so zu sagen hat[1]. pl liegt hier einfach falsch.
Hallo,
Content-Type
Wieso wird eigentlich im Wiki von Content-Type auf Zeichenkodierung weitergeleitet?
Gruß
Kalk
Hallo Tabellenkalk,
Wieso wird eigentlich im Wiki von Content-Type auf Zeichenkodierung weitergeleitet?
Danke für den Hinweis.
Bis demnächst
Matthias
Wenn ein Webserver entsprechend konfiguriert ist, hält er bei einer Anfrage (Request) mit dem Header Connection: Keep-Alive die Verbindung (Socket) offen und sendet mehrere Antwortseiten in einer einzigen Datei. Jede in dieser Datei steckende Antwortseite ist in sich komplett, enthält also alle Response-Header und den Message Body. Die einzelnen Responses mit ggf. verschiedenen Content-Type sind aneinandergehängt und ein Browser kriegt die wieder auseinander.
Auf der Suche nach anderen Programmen die das auch können, wärs gut zu wissen, wie der Content-Type heißt. Vorschläge?
Ist ja auch egal. Ich habe meinen Parser längst fertig. Er stellt aus der beschriebenen Response die Einzelnen Parts wieder her, egal welchen Content-Type die im Einzelnen sind. Grafik, Video, Text usw., schön getrennt als sog. Slice.
In Perl ein Array mit Hash-Referenzen als Array-Elemente, Schema: [{}, {}, {}]
Jede Hashref hat die Response-Header als Key => Value, hinzu kommt body => message_body und statuscode/statusmesg, ie, statuscode => 200.
Wer nur die Header braucht, eine spez. Methode liefert den Slice auch ohne Bodies.
Bisher ist das Modul für den Eigenbedarf (HTTP und HTTPS). Auf CPAN gibt es sowas noch nicht. pl
Ein Beispiel. Damit's nicht zuviel wird, nur HEAD Requests. Da gibt es keine Bodies, wenn die Dabei wären (Method != HEAD), stünden die unter den jeweiligen Headers.
Ich hab mal 2 verschiedene Seiten genommen und einen Proxy. Natürlich geht das auch ohne Proxy wenn der Wbserver entsprechend konfiguriert ist.
Matthias Apsel
Gunnar Bittersmannmy $r = HTTPRequest->new(
host => 'www-proxy.t-online.de',
timeout => 1,
http => 1.1
) or die $@;
$r->request(
Connection => 'Keep-Alive',
uri => 'http://forum.selfhtml.org',
method => 'HEAD'
);
$r->request(
method => 'HEAD',
uri => 'http://yahoo.com',
Connection => 'Close'
);
$r->print_rawdata;
# gibt aus in EINER Response
HTTP/1.1 301 Moved Permanently
Server: nginx/1.6.2
Date: Mon, 30 Nov 2015 11:49:05 GMT
Content-Type: text/html
Content-Length: 184
Location: https://forum.selfhtml.org/
X-Cache: MISS from l-squidlb-a01.isp.t-ipnet.de
X-Cache-Lookup: MISS from l-squidlb-a01.isp.t-ipnet.de:80
Via: 1.1 l-squid-a01.isp.t-ipnet.de (squid)
Connection: keep-alive
HTTP/1.1 301 Moved Permanently
Date: Mon, 30 Nov 2015 11:49:05 GMT
Server: ATS
Location: https://www.yahoo.com/
Content-Type: text/html
Content-Language: en
Cache-Control: no-store, no-cache
Y-Trace: BAEAQAAAAAApDp.hi0ningAAAAAAAAAAbFIIFd5vMAUAAAAAAAAAAAAFJcCgzzsaAAUlwKDPPxHCkrnCAAAAAA--
Content-Length: 373
X-Cache: MISS from l-squidlb-a01.isp.t-ipnet.de
X-Cache-Lookup: MISS from l-squidlb-a01.isp.t-ipnet.de:80
Via: http/1.1 ir11.fp.gq1.yahoo.com (ApacheTrafficServer), 1.1 l-squid-a01.isp.t-ipnet.de (squid)
Connection: close
Tach,
# gibt aus in EINER Response
nein, eine Connection mit zwei Responses.
mfg
Woodfighter
Tach,
# gibt aus in EINER Response
nein, eine Connection mit zwei Responses.
Programmiertechnisch ist es eine Response, die aus dem Socket gelesen wird. Aus HTTP-Sicht ist es ebenfalls eine Response.
Ein Socket ist wie eine PIPE. Gerne gehen wir das mal für einen Request durch, wir senden Keep-Alive und schalten auf Listen. Was stellen wir fest? Richtig, es dauert ne ganze Weile, bis die Response kommt. Was daran liegt, dass der Server ebenfalls gewartet hat, nämlich darauf, ob noch weitere Requests kommen.
Daher schickt ein Webserver die Response erst dann, wenn nach einer gewissen Zeit (einstellbar) keine weiteren Requests am Server ankommen.
Und jetzt kommt das, was hier vielen nicht klar ist: Wenn ein Webserver eine Response gesendet hat, schließt er die Verbindung. Verbindung offenhalten heißt also aus der Sicht des Webservers: Nicht senden sondern warten.
Und Senden heißt: Das Warten ist beendet, Response senden, Connection: Close.
Gerne schreibe ich das mal be Gelegenheit ewtas ausführlicher auf, ich hab das zwar nicht stuiert aber ih hab mich sehr ausführlich damit befasst und ein praktikables Perl Modul dazu entwickelt.
Aber ich erklärs nicht nochmal jedem Einzelnen hier, bei soviel Ignoranz und arroganz die mir hier entgegenspringt. Echt der Hammer.
Was macht eigentlich Dein XML-Parser? Kann man schon etwas sehen?
Was macht eigentlich Dein XML-Parser? Kann man schon etwas sehen?
Ich entwickle keine XML Parser. Dafür seit Jahren Serializer. Ein sequentielles Lesen der Response ist unbedingt erforderlich, weil die einzelnen Parts auch Binärdaten darstellen können. Ein einfaches Splitten ode Tokenizing der Response-Datei ist demnach nicht zielführend <= für den hier beschriebenen Content-Type ohne Namen.
Achja, bei der Gelegenheit: XML ist Schrott. MIME auch. Mehr dazu auf meinem Blog ;)
@@pl
Achja, bei der Gelegenheit: XML ist Schrott. MIME auch. Mehr dazu auf meinem Blog ;)
Du solltest deine Weisheiten nicht in deinem Blog verkümmern lassen, wo sie die Fachwelt vielleicht nicht wahrnimmt. Raus damit! Du hast noch gut zwei Stunden Zeit, deinen Vortrag für die XML Prague einzureichen.
LLAP 🖖
Bloggen ist die einzige Möglichkeit, Frust loszuwerden, der sich in den letzten Jahren da angesammelt hat, wo statt produktiver Arbeit nur noch Mobbing angesagt ist. Gottseidank bin ich da raus.
Aber anstatt nur zu polemisieren warum XML Schrott ist, zeige ich ja auf meinen Seiten, wie es besser gemacht werden könnte, nämlich unter Beachtung und Würdigung uralter Erkenntnisse und als praktische Anwendung der Lehre alter Meister wie z.B. Niklaus Wirth.
Leute, lest die richtigen Bücher.
PS: Status von 200 URLs prüfen dauert mit HTTP/1.0 30 Sekunden, weil es 200 Request/Response-Zyklen sind. Mit HTTP/1.1 und Keep-Alive ist es nur noch ein Request und bis zur Ausgabe der Response-Datei welche den Status von 200 URLs beschreibt dauert alles zusammen nur noch 3 Sekunden.
http://handwerkzeugs.de/httpconn.html
Tach!
http://handwerkzeugs.de/httpconn.html
Du erzählst dort Sachen, die mit der Realität nichts zu tun haben. Eine Verbindung ist keine Datei und man kann sie auch nicht mit einer solchen vergleichen. Das passt hinten und vorn nicht. Über eine Verbindung kann man bunt durcheinander Daten in beide Richtungen senden und nicht erst in die eine und an Ende in die andere Richtung. Sonst könnte man sowas wie Telnet oder SSH oder RDP nicht zum Fernbedienen von Maschinen verwenden.
Bei Connection: keep-alive wartet der Webserver mitnichten darauf, dass irgendwann noch ein Request mit Connection: close hinterherkommt. Sobald das zweite CRLF kommt, gibt es Antwort zu diesem Request. Nachvollziehbar mit telnet auf Port 80 und
GET / HTTP/1.1
Host: localhost
Connection: keep-alive
Nach dem Request bleibt die Verbindung noch ein paar Sekunden offen und wird dann geschlossen, wenn nichts mehr kommt. Nach deiner Argumentation dürfte der Webserver gar keine Antworten senden, weil er beim Timeout gar kein Connection: close zu Gesicht bekommt.
dedlfix.
Tach!
Nachtrag zum HTTP-Pipelining. Es ist erst ab HTTP 1.1 verfügbar, dass ein Client mehrere Requests abschicken kann, ohne jeweils erst auf die Antwort warten zu müssen. Es ist dazu nichts weiter notwendig, also kein zusätzlicher Datenaustausch, mit dem ermittelt wird, ob dieses Feature überhaupt anwendbar ist. Aber, wie gesagt, das gibt es erst ab HTTP 1.1. Dazu muss der Client zunächst erst einmal in Erfahrung gebracht haben, ob der Server dieses auch beherrscht. Das geht am besten, in einer Verbindung, in der bereits ein Request mit keep-alive abgesetzt wurde, woraufhin man in der zugehörigen Antwort in der ersten Response-Header-Zeile das HTTP 1.1 erkennen kann.
Der Server kann nicht erkennen, ob der Client Pipelining machen möchte oder nicht. Es kann also auch nicht wissen, ob er warten soll, bis der Client fertig hat oder sofort antworten soll. Abgesehen davon, dass Pipelining auch nicht heißt, dass erstmal alle Requests beim Server angekommen sein müssen, bevor dieser darauf antworten darf.
Es ist also auch mit Pipelining nicht zu begründen, dass ein Webserver erst ein Connection: close abwartet, bevor er die Antworten schickt.
Programmtechnisch muss man im einfachsten Fall auf dem Server gar nichts machen, um Pipelining zu unterstützen, wenn der TCP/IP-Stack einen ausreichend großen Puffer enthält, in dem die empfangenen Daten erstmal zwischengespeichert werden, bevor sie die Webserver-Software abfragt. Letztere kann dann einfach bis zum doppelten CRLF lesen, den Request verarbeiten und beantworten. Anschließend liest sie weiter aus den gepufferten Daten bis zum nächsten CRLF² und so weiter und so fort.
dedlfix.
Hallo,
... doppelten CRLF ...
nächsten CRLF² ...
was denn nun? zweifacher CRLF oder quadratischer CRLF, kannst du dich bitte mal entscheiden?
Gruß
Kalk
PS: ;)
Tach!
... doppelten CRLF ...
nächsten CRLF² ...was denn nun? zweifacher CRLF oder quadratischer CRLF, kannst du dich bitte mal entscheiden?
Kann ich nicht ;) Manchmal nehme ich Synonyme, um nicht immer so wiederholend zu klingen.
dedlfix.
@@Tabellenkalk
was denn nun? zweifacher CRLF oder quadratischer CRLF, kannst du dich bitte mal entscheiden?
Das ist doch dasselbe, sagte die Zwei.
LLAP 🖖
@@Gunnar Bittersmann
was denn nun? zweifacher CRLF oder quadratischer CRLF, kannst du dich bitte mal entscheiden?
Das ist doch dasselbe, sagte die Zwei.
Und die Null stimmte zu. (Das war trivial.)
LLAP 🖖
Hallo,
Das ist doch dasselbe, sagte die Zwei.
Und die Null stimmte zu. (Das war trivial.)
diese beiden haben da aber echt eine Minderheitenmeinung, sie sollten ein Blog aufmachen.
Gruß
Kalk
Hallo dedlfix,
Es ist also auch mit Pipelining nicht zu begründen, dass ein Webserver erst ein Connection: close abwartet, bevor er die Antworten schickt.
Sag ich doch.
Technisch ist Pipelining auf Server-Seite idR so implementiert, dass entweder gar nichts gemacht wird (dann sorgt der Buffer dafür, dass es funktioniert) oder so implementiert, dass via Multiplexing immer wieder gelesen und geschrieben wird wenn der Socket gerade dazu bereit ist. Denn auch ausgehender Traffic hat ja einen Buffer, der irgendwann voll ist: der ideale Zeitpunkt um den nächsten Request zu lesen.
LG,
CK
Hi,
# gibt aus in EINER Response
nein, eine Connection mit zwei Responses.
Programmiertechnisch ist es eine Response, die aus dem Socket gelesen wird. Aus HTTP-Sicht ist es ebenfalls eine Response.
nein, falsch. Hättest du gesagt ein Stream, dann hätte man noch nicken können. Aber aus HTTP-Sicht sind es definitiv ZWEI Responses, nämlich auf zwei unterschiedliche Requests.
Dein gewähltes Beispiel macht's sogar noch interessanter, weil es zwei Requests sind, die an unterschiedliche Server gehen, und der Proxy führt die Responses zusammen, bezieht das Keep-Alive also konkret auf die Strecke Client-Proxy.
Ein Socket ist wie eine PIPE. Gerne gehen wir das mal für einen Request durch, wir senden Keep-Alive und schalten auf Listen. Was stellen wir fest? Richtig, es dauert ne ganze Weile, bis die Response kommt.
Richtig, weil der Server eine endliche Zeit braucht, um den Request zu bearbeiten. Ganz zu schweigen von der Übermittlung, eventuell über mehrere Hops. So dauert es also gut und gerne mal ein paar Zehntelsekunden, bis die Antwort vom Server überhaupt eintreffen kann.
Was daran liegt, dass der Server ebenfalls gewartet hat, nämlich darauf, ob noch weitere Requests kommen.
Falsch. Sobald der erste Request da ist (erkennbar am doppelten Zeilenumbruch), fängt er sofort mit der Bearbeitung an. Trifft während dieser Zeit ein weiterer Request ein, landet der in der Warteschlange und wird ebenfalls bearbeitet, sobald der erste fertig ist.
Daher schickt ein Webserver die Response erst dann, wenn nach einer gewissen Zeit (einstellbar) keine weiteren Requests am Server ankommen.
Falsch. Ein solches Verhalten wäre Gift für die Performance. Kein Kommunikations-Fachmann wird absichtlich Totzeiten einbauen.
Und jetzt kommt das, was hier vielen nicht klar ist: Wenn ein Webserver eine Response gesendet hat, schließt er die Verbindung.
Ja, außer der zugehörige Request sagte "Connection: Keep-Alive".
Verbindung offenhalten heißt also aus der Sicht des Webservers: Nicht senden sondern warten.
Falsch. Es heißt, senden, dann die Verbindung bestehen lassen.
Und Senden heißt: Das Warten ist beendet, Response senden, Connection: Close.
Falsch.
Gerne schreibe ich das mal be Gelegenheit ewtas ausführlicher auf, ich hab das zwar nicht stuiert aber ih hab mich sehr ausführlich damit befasst und ein praktikables Perl Modul dazu entwickelt.
Blödsinn. Du kannst nicht ausgerechnet in einem Fach-Forum so einen Unfug erzählen und dann auch noch erwarten, dass alle anderen anerkennend nicken oder ehrfürchtig leise "Boah!" sagen. Das kannst du bei der Jahreshauptversammlung des Baumwollpflücker-Vereins erzählen, da glaubt dir vielleicht auch noch der eine oder andere.
Aber ich erklärs nicht nochmal jedem Einzelnen hier, bei soviel Ignoranz und arroganz die mir hier entgegenspringt. Echt der Hammer.
Tja ... das ist ja leider kein Einzelfall. Du bist notorisch dafür bekannt, ja fast berühmt, regelmäßig Räder neu zu erfinden, dabei Lösungen von hinten durch die Brust ins Knie zu finden, die zum Teil auch noch auf falschen Annahmen beruhen und vielleicht in einem sehr speziellen Ökosystem funktionieren, vielleicht auch nur, weil ein Denkfehler und eine Fehlerbehandlung "auf Verdacht" sich kompensieren.
So, das musste jetzt mal gesagt werden.
So long,
Martin