UMTS / Base Internetzugang - Erfahrungen/Caching

Jürgen Auer

Jürgen Auer

Legendäres Mitglied
Hat jemand hier Erfahrungen mit UMTS-Nutzung bzw. der Base - Flatrate von ePlus?

Folgendes Problem:

Ein Nutzer ruft einen Datensatz auf, editiert ihn.

Speichert bzw. will speichern, klickt auf den Speichern-Button.

Das kommt beim Server an, da wird gemeckert, weil das Format für eine Eingabe in einem Feld nicht korrekt ist.

Normal: Alle Felder sind mit den davor eingegebenen bzw. schon gespeicherten Werten belegt, das Feld mit dem Fehler hat zusätzlich einen roten Text drüber.

Nun: Lediglich das 'angemeckerte Feld' ist gefüllt, der Rest ist leer.

Der Nutzer ändert das, reagiert auf den Rest nicht, klickt auf Speichern - der Datensatz wird 'fast leer' gespeichert (mit Ausnahme des einen editierten Feldes). Klar - der Browser hat meistens leere Felder geschickt, also denkt der Code auf dem Webserver, das solle so sein (waren keine Pflichtfelder).


Die Daten haben sich nochmals aus der letzten Sicherung herstellen lassen. Aber auf Dauer ist das natürlich extrem unbefriedigend.

Ein Bedienfehler ist praktisch ausgeschlossen - der Kunde hat bereits tonnenweise Daten eingegeben (auch mit 'Meckern'). Ähnliches gilt für Fehler im Code (von meiner Seite her) - das ist ein Kernfeature, das seit drei Jahren läuft.

Gibt es irgendwelche Konfigurationsmöglichkeiten für diesen UMTS-Internetzugang, über die man das Caching komplett deaktivieren kann? Klar - das ist eine Flatrate, der Provider will möglichst wenig Traffic produzieren. Aber so ist das nicht nutzbar.


Any help greatly appreciated.
 
Hatten mal ein Problem wo der Client die Verschlüsselung abstellen musste bei Zugang über UMTS. War Provider-Eigenbau-Irgendwas-Würg Verschlüsselung. Sonst hab ich immer gute Erfahrungen gemacht die Action URL also das Ziel des Formulares mit Zufallszahlen zu schmücken wenn es um ungewolltes Caching geht. Die Browser schlucken das eigentlich immer als Unikat. Aber so wirklich Erfahrung hab ich nicht, war nicht der Client.
 
Danke für den Hinweis.

Ich habe das jetzt mal testweise so eingebaut, daß das nur auf den internen Masken dieses Kunden wirkt. Das Login funktioniert, da gibt es das Problem nicht. Damit ist das im Prinzip bloß eine einzige Stelle innerhalb der Xsl-Transformationsdatei, wo der Wert für das form-action - Attribut ermittelt wird. Das verzweigt nun nach dem Hostnamen dieses Kunden.

Sieht eben jetzt so aus:

QUOTE action="/de/personen.html/iP/mlm/mln/oP?___tId=-8589684271923607683"



Die Zahl gibt es ohnehin, das ist ein Timer, mit dem man bsp. bei Kontaktformularen schön dafür sorgen kann, daß mindestens 5 Sekunden zwischen Aufruf und Absenden der Seite verstrichen sein müssen.


Da das bloß für die Formulare relevant ist, müßte das alle Fälle abdecken. Umgekehrt ist mir das jetzt ad hoc viel zu riskant, das auf dem Gesamtsystem zu machen. Falls irgendetwas schief gehen würde, wären da aktuell ohnehin bloß genau jene Nutzer davon betroffen, die das Problem beobachtet haben.

Normalerweise suche ich ja zunächst Fehler gerne bei mir selbst. Aber wenn das schon häufiger aufgetreten wäre, dann hätten Kunden längst schon getobt - insofern kann es eigentlich nur an der Art des Zugangs liegen.
 
Läuft das bereits über SSL? Falls nicht, wäre vielleicht eine Möglichkeit. Ich würde mal behaupten, dass ein Provider-Cache bei einer SSL-Verbindung nicht cachen kann.
 
QUOTE (retok @ Mi 28.01.2009, 23:20)Läuft das bereits über SSL? Falls nicht, wäre vielleicht eine Möglichkeit. Ich würde mal behaupten, dass ein Provider-Cache bei einer SSL-Verbindung nicht cachen kann.

Ein ähnliches Problem mit dem 'neuen Zugang' war schon bei Xing mit SSL aufgetreten.

Da haben auch plötzlich Dinge nicht mehr funktioniert, die mit normalem Breitbandzugang geklappt haben.
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben