nicht angemeldet
Daten-"Übertragung" Server -Client
Rolf bHallo, wenn man Daten die serverseitig generiert werden gibt es ja die beiden Hauptansätze von entweder direkt in dem Dokument zu generieren (sprich "ins HTML schreiben") oder dann per AJAX anfordern.
Das eine hebelt das Caching aus, das anderer erfordert eine neue Anfrage, also beides nicht so prickelnd. Da hab ich mir die Frage gestellt, warum nicht einfach über Cookies diese Daten zu übermitteln. Also Cookie wird bei der Antwort mit den Daten gesetzt, von JS verarbeitet und der Cookie wieder gelöscht Vorteile die ich sehe: Keine Caching-Hürde, kein zusätzliches Request Nachteil: Cookies haben eine maximale Länge
Wie ist eure Meinung dazu? Welche Vor-/Nachteile seht ihr dabei?
MfG Regina Schlauklug
-
hi,
Wie ist eure Meinung dazu? Welche Vor-/Nachteile seht ihr dabei?
Es gibt immer 2 Möglichkeiten wo die Daten sind:
- Daten sind in einem Header, nur ASCII, max 8k (lt. stackoverflow u. eigenen Tests),
- Daten sind im Message-Body, Bytes beliebiger Wertigkeiten, unlimited.
Ein Cookie siehe (1).pl
-
- Daten sind in einem Header, nur ASCII, max 8k (lt. stackoverflow u. eigenen Tests),
- Daten sind im Message-Body, Bytes beliebiger Wertigkeiten, unlimited. Ein Cookie siehe (1).pl
Okay, quasi genau das, was ich gesagt hab (außer dass du die Länge bestimmt hast – ist bei mir übrigens nach einigen Versuchen nur 4096 Byte), aber noch immer keine Antwort auf meine Frage nach Vor-/Nachteilen bezüglich der Cookies.
Gibt es überhaupt noch was anderes dazu zu sagen?
-
- Daten sind in einem Header, nur ASCII, max 8k (lt. stackoverflow u. eigenen Tests),
- Daten sind im Message-Body, Bytes beliebiger Wertigkeiten, unlimited. Ein Cookie siehe (1).pl Okay, quasi genau das, was ich gesagt hab (außer dass du die Länge bestimmt hast – ist bei mir übrigens nach einigen Versuchen nur 4096 Byte), aber noch immer keine Antwort auf meine Frage nach Vor-/Nachteilen bezüglich der Cookies.
Gibt es überhaupt noch was anderes dazu zu sagen?
Wie schon gesagt: Ein Cookie ist auch nur ein Header ;)
Damit's ASCII bleibt, gibt's ja verschiedene Möglichkeiten, Prozentkodierung, Base64 um nur 2 zu nennen. Mit einem ganz normalen prozentkodierten QUERY_STRING kannst Du sogar strukturierte Daten in einem Header bzw. Cookie-Value senden. Für meinen letzten Advendskalender hab ich z.B. 48 verschiedene Zustände in einem Cookie übertragen.
Anstelle eines Cookies würds ein Custom-Header sicher auch tun. Menn Du den body überhaupt nicht brauchst, reicht auch ein HEAD Request, d.h., die ganze Kommunikation wird nur über die Header abgewickelt. mfg
-
QUERY_STRING
kann es sein das wir an einander vorbei reden? Ich rede von Server-zu-Client-Datenübertragung, da weiß ch nicht wirklich wie ich da was mit dem Querystring machen kann.
Anstelle eines Cookies würds ein Custom-Header sicher auch tun.
Kann man mit Javascript die Header auslesen die für die Initialanfrage geschickt wurden? Wenn ja, wie?
-
QUERY_STRING kann es sein das wir an einander vorbei reden? Ich rede von Server-zu-Client-Datenübertragung, da weiß ch nicht wirklich wie ich da was mit dem Querystring machen kann.
Anstelle eines Cookies würds ein Custom-Header sicher auch tun. Kann man mit Javascript die Header auslesen die für die Initialanfrage geschickt wurden? Wenn ja, wie?
Ja Freilich ;)
// CustomHeader x-data // beim Empfang xhr.getResponseHeader('x-data'); // Senden xhr.setRequestHeader('x-data','123'); // am Server in HTTP_X_DATA zu findenBeispiel (nur Senden)
-
-
Ich bin kein Experte im HTTP Protokoll, aber ein schneller google liefert mir RFC 2616 Section 10 und danach scheint mir, als wäre das, was du vorhast, nicht protokollkonform.
Rolf
-
RFC 2616 Section 10
Da geht's doch nur um die verschiedenen Statuscodes, von Cookies wird da nicht gesprochen, soweit ich das gerade überblicken kann.
das, was du vorhast
Das was ich vorhab wird sowieso in keinem RFC stehen (vermute ich)
-
Da geht's um Header, wozu die Kekse gehören, und zum 304 gibt es Regeln.
-
-
-
Tach!
Das eine hebelt das Caching aus, das anderer erfordert eine neue Anfrage, also beides nicht so prickelnd. Da hab ich mir die Frage gestellt, warum nicht einfach über Cookies diese Daten zu übermitteln.
Das ist noch weniger prickelnd.
Wie ist eure Meinung dazu? Welche Vor-/Nachteile seht ihr dabei?
Die Frage ist: Will man irgendwas basteln, das möglicherweise wegen seiner Ungewöhnlichkeit Probleme bereitet, oder nimmt man lieber die kleinen Nachteile bewährter Methoden in Kauf?
dedlfix.
-
Die Frage ist: Will man irgendwas basteln, das möglicherweise wegen seiner Ungewöhnlichkeit Probleme bereitet, oder nimmt man lieber die kleinen Nachteile bewährter Methoden in Kauf?
Deswegen bin ich ja hier und frage die Wissenden, ob es schwerwiegende Nachteile gibt ;)
-
Genau diesen Kommentar hatte ich mir verkniffen, weil ich mir nicht zugetraut hatte, dieses Vorgehen in "cleverer Trick" oder "99 Wege sich in den Fuß zu schießen" einzuordnen. Die Frage, ob man damit im Definitionsbereich des HTTP Protokolls ist, sollte aber auf jeden Fall noch jemand beleuchten.
Rolf
-
-
Das eine hebelt das Caching aus, das anderer erfordert eine neue Anfrage, also beides nicht so prickelnd.
Auch das Cache-Verhalten für Ajax hast Du in der Hand. Da kannst Du genauso HTTP-Header setzen wie das ein ordinärer Browser tut unabhängig von Letzterem. mfg
-
Hi,
ich weiss nicht, ob du mit weisheit umgehen kannst, aber für mich riecht das stark nach premature optimization.
das bedeutet nicht, dass deine idee dumm ist. ich würde mich da eher auf http/2 verlassen, das viele der "zusätzlicher request" etc optimiert. im besonderen habe ich mit solchen "dinge für andere dinge missbrauchen" unerwartete erfahrungen gemacht, z.b. könnte ich mir bei deiner lösung gut vorstellen, dass du in buffer probleme rennst, mit deiner software, platform, proxy, reverse proxy. in filterprobleme mit "application firewalls", "web security tools".
ich würde dir raten, es einfach vernünftig zu messen. so ein experiment kostet nicht viel zeit, erspart aber eine menge ärger.