-
TECHNISCHES
GEBIET
-
Fehlerbenachrichtigungsverfahren
in HTTP-basierten Kommunikationssystemen
-
Die
vorliegende Erfindung betrifft ein Handhaben von Nachrichten in
Kommunikationsnetzwerken und im Besonderen ein Fehlerbenachrichtigen
für eine
Kommunikation basierend auf dem Hypertext Transfer Protocol (HTTP).
-
HINTERGRUND
-
Heute
kommunizieren praktisch sämtliche
Web-Server, Clients und bezogene Web-Anwendungen miteinander durch
HTTP. Die Kommunikation basiert auf HTTP-Anforderungen und -Antworten
zwischen Clients und Servern, für
welche HTTP ein Anforderungs-Antwort-Protokoll definiert. Jedesmal
wenn ein Client eine HTTP-Anforderung sendet, gibt der Web-Server
einen MIME-(Multipurpose Internet Mail Extensions) Header zurück.
-
Die
Startzeile der Antwort liest sich:
<version> <status
code> <reason phrase>
-
Der
version Teil bezieht sich auf die für die Nachricht verwendete
HTTP-Version. Der status code (Statuscode) ist eine dreiziffrige
Codezahl, die grob angibt, was während
der Anforderung geschah. Statuscodes sind in allgemeine Klassen
gruppiert, die durch die erste Ziffer beschrieben werden. Zum Beispiel
bedeuten Codes im Format 2XX "Erfolg", wohingegen 4XX
und 5XX Codes einen "Client-Fehler" bzw. einen "Server-Fehler" angeben. Die reason
phrase (Grundphrase) ist schließlich
eine durch einen Menschen lesbare Version der Codezahl, deren Eigenschaften
unten beschrieben werden. Die Standard HTTP-Antwort auf eine erfolgreiche GET-Anforderung
ist:
HTTP/1.0 200
-
Der
obigen Zeile folgen typischer Weise weitere Header-Informationen, wie
beispielsweise Inhaltstyp und Länge,
und dann das angeforderte Dokument.
-
Ein
allgemein verwendetes Kommunikationsnetzwerk nach dem Stand der
Technik umfasst einen Web-Server, der mit einem Client-Endgerät über einen
Proxy-Server (im Allgemeinen als "Proxy" bezeichnet) kommuniziert. Der Proxy
mischt bzw. schaufelt HTTP-Nachrichten zwischen dem Server und dem
Client hin und zurück.
Genauer genommen überbringt
der Proxy jede Anforderung, die auf HTTP basiert oder auf dem Wireless
Session Protocol (WSP), von dem drahtlosen Client an den Web-Server und jede nachfolgende HTTP-Antwort
von dem Web-Server an den Client. Die Startzeile der Antwort passiert
den Proxy unverändert, und
der Endbenutzer empfängt
eine Antwortnachricht, die direkt der von dem Web-Server gesendeten
Antwort entspricht.
-
Dokument
WO-A-01/57666 offenbart ein Portal, das HTML-Codes übersetzt.
-
Nun
sei angenommen, dass der Server auf einen Fehler trifft, und dieses
in der HTTP-Antwort berichtet. Für
solch einen Fall (HEAD-Anforderungen ausgenommen) erklärt das HTTP-Protokoll,
dass der Server "eine
eine Erläuterung
der Fehlersituation enthaltende Entität enthalten sollte" ("should include an
entity containg an explanation of the error situation") in der Antwort
("Hypertext Transfer
Protocol – HTTP/1.1", RFC 2616, R. Fielding
et al., Juni 1999). Darüber
hinaus ist festgelegt, dass Benutzeragenten "irgendeine enthaltene Entität dem Benutzer
anzeigen sollten" ("should display any
included entity to the user").
Dies bedeutet, dass dort eine Erläuterungsentität sein kann – oder nicht
sein kann –,
d.h. eine Grundphrase, die in der Antwortnachricht enthalten ist.
Selbst wenn eine Grundphrase vorliegt, ist es darüber hinaus
nicht gewiss, dass sie dem Endbenutzer präsentiert werden wird. Manchmal
wird nur der Fehlercode angezeigt. Der Provider des angeforderten
Dienstes, z.B. ein Mobiloperator, kann möglicherweise nicht wissen,
was in einer bestimmten Fehlersituation geschehen wird.
-
Selbst
wenn eine Grundphrase gezeigt wird, kann sie darüber hinaus die tatsächliche
Fehlersituation sehr schlecht oder sogar fehlerhaft wiedergeben.
Die HTTP-Spezifikation gibt keine Anleitung hinsichtlich des exakten
Textes für
Grundphrasen, die daher eher beliebig sind. Folglich kann der Endbenutzer
einen falschen Eindruck über
den Dienst-Provider bekommen, was ein sehr ernsthaftes Problem ist,
da es den Wert des Dienstes in den Augen des Benutzers reduziert.
-
Dem
gemäß ist ein
konventionelles Handhaben von HTTP-Fehlernachrichten weit entfernt von
einem zufriedenstellenden Zustand, und es gibt einen beträchtlichen
Bedarf für
ein verbessertes Fehlerbenachrichtigungsverfahren.
-
ZUSAMMENFASSUNG
-
Es
ist eine allgemeine Aufgabe der vorliegenden Erfindung, ein verbessertes
Fehlerhandhaben in HTTP-Kommunikationssystemen gemäß den unabhängigen Ansprüchen 1,
9 und 16 bereitzustellen. Es ist eine spezifischere Aufgabe, verlässliche
und informative Fehlernachrichten für eine Client-Server-Kommunikation durch
ein Zwischengerät
zu erreichen.
-
Diese
Aufgaben werden gemäß den beigefügten Ansprüchen erreicht.
-
Kurz
gesagt nutzt das Verfahren der vorliegenden Erfindung das Zwischengerät, das ein
drahtloses Client-Endgerät
und einen Web-Server zusammenschaltet, um eine Steuerung von, von
dem Server gesendeten, Fehlernachrichten zu erreichen. Der von dem
Server gesendete Fehlerstatuscode wird in eine informative Fehlerbeschreibungsnachricht
transformiert, die einen erweiterten Fehlerbeschreibungstext als
auch einen neuen Statuscode enthält.
Der neue Statuscode wird vorzugsweise gewählt, so dass er eine Anzeige
des Fehlerbeschreibungstextes erzwingt bzw. durchsetzt. Auf diese
Weise ist es möglich,
zu steuern, welche Nachricht ein Endbenutzer in Ansprechen auf eine
erfolglose Anforderung empfangen wird, und auch zu garantieren,
dass die Nachricht tatsächlich
bei dem Client-Endgerät angezeigt
wird. Die Erfindung ist auf eine HTTP-basierte Kommunikation anwendbar und
vorzugsweise in einem Proxy-Server durch eine Fehlerinformationstabelle
implementiert, die Ressourcenstandort-abhängige Fehlerbeschreibungsnachrichten
bereitstellt.
-
Gemäß einem
anderen Aspekt der Erfindung ist ein Proxy-Server mit einer Fehlerbenachrichtigungseinrichtung
bereitgestellt. Eine Fehlerbenachrichtigungseinrichtung für eine Multimedia
Messaging Service (MMS) Kommunikation ist ebenso bereitgestellt.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die
Erfindung, zusammen mit anderen Aufgaben und Vorteilen davon, kann
am besten mit Verweis auf die folgende Beschreibung zusammen mit
den begleitenden Zeichnungen verstanden werden.
-
1 ist
eine schematische Übersicht
eines beispielhaften Netzwerkes für eine Kommunikation zwischen
drahtlosen Clients und einem Web-Server;
-
2 ist
ein schematisches Blockdiagramm, das ein konventionelles Fehlerbenachrichtigen
bei einer Client-Server-Kommunikation durch ein Zwischengerät veranschaulicht;
-
3 ist
ein schematisches Blockdiagramm, das ein konventionelles Fehlerbenachrichtigen
für ein System
mit einem externen Web-Server veranschaulicht;
-
4 ist
ein schematisches Blockdiagramm, das ein konventionelles Fehlerbenachrichtigen
für eine MMS-Kommunikation veranschaulicht;
-
5 ist
ein schematisches Blockdiagramm einer beispielhaften Ausführungsform
eines Fehlerbenachrichtigungssystems gemäß der vorliegenden Erfindung;
-
6 veranschaulicht
ein Wiedergewinnen einer Fehlernachricht gemäß einer beispielhaften Ausführungsform
der vorliegenden Erfindung;
-
7 ist
ein schematisches Blockdiagramm einer beispielhaften Ausführungsform
eines Fehlerbenachrichtigungssystems zur MMS-Kommunikation gemäß der vorliegenden
Erfindung;
-
8 ist
ein schematisches Blockdiagramm einer anderen beispielhaften Ausführungsform
eines Fehlerbenachrichtigungssystems zur MMS-Kommunikation gemäß der vorliegenden
Erfindung;
-
9 ist
ein Flussdiagramm einer beispielhaften Ausführungsform eines Fehlerbenachrichtigungsverfahrens
gemäß der vorliegenden
Erfindung.
-
DETAILLIERTE
BESCHREIBUNG
-
In
sämtlichen
Zeichnungen werden dieselben Bezugsziffern für ähnliche oder entsprechende
Elemente verwendet.
-
1 ist
eine schematische Übersicht
eines beispielhaften Netzwerks zur Kommunikation zwischen drahtlosen
Clients und einem Web-Server. Es ist ein Kommunikationssystem gezeigt,
das auf der einen Seite eine Anzahl von drahtlosen Client-Endgeräten 10-1, 10-2, 10-3,
wie beispielsweise Mobiltelefonen, Pagern und Laptops, und auf der
anderen Seite einen Web-Server 30 umfasst. Das System enthält ferner
einen Proxy-Server 20, ein Zwischengerät, das eine Brücke zwischen
dem Mobilnetzwerk 15 und den Diensten im Internet 25 bildet.
Der Proxy 20 kann z.B. ein Nachrichtenfiltern und/oder
ein Bereitstellen von Sicherheitslösungen und anderen Diensten
durchführen.
In der Praxis umfassen die meisten Kommunikationssysteme mehrere Proxies
und Server, die in einem komplexeren Netzwerk als in dem grundlegenden
Beispiel von 1 angeordnet sind.
-
Wie
in dem Hintergrundabschnitt umrissen, ist die Fehlerinformation,
die ein Endbenutzer bei einer Client-Server-Kommunikation durch ein Zwischengerät empfängt, im
Allgemeinen unzulänglich.
Die Situation ist in 2 veranschaulicht, welche ein
schematisches Blockdiagramm eines konventionellen Fehlerbenachrichtigens
zweigt. Ein drahtloses Client-Endgerät 10 ist über einen
Proxy-Server 20 mit einem Web-Server 30 verbunden.
Der drahtlose Client 10 sendet eine GET-Anforderung an
den Proxy 20, der die Nachricht an den Web-Server 30 überbringt.
Wie in der Zeichnung angegeben, kommunizieren der Client 10 und
Proxy 20 miteinander durch entweder das WSP- oder das HTTP-Protokoll.
WSP ist gegenwärtig
die meist verbreitete Sprache für
diesen Kommunikationstyp. Jedoch ist die Kommunikation zwischen
dem Proxy 20 und Web-Server 30 immer
HTTP-basiert. Der Web-Server 30 von 3 stößt auf einen
Fehler beim Verarbeiten der Anforderung und sendet eine Antwort
mit z.B. dem Statuscode 500 für "Server-Fehler" an den Proxy 20,
der die Antwortstartzeile unverändert
an das Client-Endgerät 10 weiterleitet.
Die Antwort kann oder kann nicht die ziemlich beschränkte Grundphrase
enthalten, die in dem Hintergrundabschnitt beschrieben ist, die
bei dem Client-Endgerät 10 angezeigt
werden kann oder nicht angezeigt werden kann.
-
Es
ist aus 2 ersichtlich, dass der Endbenutzer
sieht, was ihn der Web-Server im Sinne einer Fehlerinformation sehen
lässt.
Dieses ist besonders problematisch für Situationen wie die der in 3 gezeigten, wo
ein externer Web-Server eingesetzt wird. Der Web-Server befindet
sich außerhalb
der Steuerungsreichweite 40 des Mobiloperators, z.B. im
Internet. Eine Fehlernachricht, in diesem Beispiel mit dem Fehlerstatuscode 400,
wird von dem externen Web-Server 30 gesendet, passiert
den Proxy 20, und wird bei dem Client- Endgerät 10 empfangen. Der
Endbenutzer sieht bestenfalls eine dürftige Grundphrase, aber er
kann auch mit dem recht unbegreiflichen Fehlerstatuscode alleingelassen
werden, und es ist wahrscheinlich, dass er den Eindruck bekommt,
dass der Mobiloperator eine schlechte Dienstqualität hat. Der
Mobiloperator kann die Existenz und den Wortlaut einer möglichen
Grundphrase nicht beeinflussen.
-
Probleme
des oben beschriebenen Typs treten auch bezüglich Diensten auf, die durch
den Mobiloperator betrieben werden, z.B. MMS. Solch eine Situation
ist in 4 dargelegt, welche ein schematisches Blockdiagramm
eines konventionellen Fehlerbenachrichtigens für eine MMS-Kommunikation ist.
Die Elemente von 4 entsprechen direkt denen von 3,
außer
für den
Server 30, welcher in diesem Fall eine MMS-Zentrale (MMSC)
ist. Man nehme z.B. an, dass der Endbenutzer MMS-Nachrichten empfangen hat, die in der MMSC 30 gespeichert
werden, und dass die Meldungen davon aus einem Grund den Endbenutzer
nicht erreichen. Sein Mobiltelefon 10 kann z.B. abgeschaltet
sein. Nach einer gewissen Zeitperiode werden die MMS-Nachrichten
von der MMSC 30 gelöscht
werden, aber wenn das Mobiltelefon 10 wieder verfügbar wird, wird
der Endbenutzer immer noch Meldungen empfangen, dass MMS-Nachrichten
in der MMSC 30 vorliegen. Bei seinem Versuch, diese einzusammeln,
wird eine Fehlernachricht angezeigt werden. Diese Fehlernachricht ist
eine HTTP-Antwort mit einem Fehlerstatuscode, welche den Proxy 20 unverändert, ähnlich wie
in den oben beschriebenen Fällen,
passiert. Es gibt keinen Weg, den Endbenutzer zu informieren, dass
die Nachrichten gelöscht
worden sind. Selbstverständlich
kann dieses zu einer Wahrnehmung führen, dass der angebotene Dienst
schlecht ist, MMS in diesem Fall, und möglicherweise zu unzufriedenen
Kunden.
-
Die
vorliegende Erfindung eliminiert die obigen Probleme, indem sie
einen Vorteil aus der Tatsache zieht, dass der Mobiloperator im
Allgemeinen den Proxy in den obigen Situationen steuert. Anstelle
eines bloßen
Weiterleitens eines Fehlerstatuscodes von dem Web-Server an das
Client-Endgerät, transformiert
der Proxy der Erfindung den Statuscode in eine Fehlerbeschreibungsnachricht
mit zwei Teilen, die zusammen in einem höchst zuverlässigen und vorteilhaften Fehlernachrichtenhandhaben
resultieren. Dies wird nun im Detail mit Verweis auf 5 und 6 beschrieben
werden.
-
5 ist
ein schematisches Blockdiagramm einer beispielhaften Ausführungsform
eines Fehlerbenachrichtigungssystems gemäß der Erfindung. Wie zuvor
passieren die Anforderungs- und Antwortnachrichten zwischen dem
drahtlosen Client-Endgerät 10 und
dem Web-Server 30 ein Zwischengerät 20, wie beispielsweise
einen Proxy-Server oder ein Gateway (hier als das frühere veranschaulicht).
Das drahtlose Client-Endgerät 10 ist
in dem Kommunikationssystem gemäß der Erfindung
als irgendeine geeignete Art eines drahtlosen Gerätes implementiert,
einschließlich
von Mobiltelefonen, Laptops und persönlichen digitalen Assistenten.
Das drahtlose Client-Endgerät 10 und
das Zwischengerät 20 können entweder
miteinander in WSP oder HTTP kommunizieren, obwohl die aktuell meist
bevorzugte Ausführungsform
der Erfindung WSP für
eine Client-Proxy-Kommunikation
verwendet. Das Zwischengerät 20 der
Erfindung kann ein WSP-Proxy/Wireless Application Protocol (WAP)-Gateway
oder ein HTTP-Proxy sein. Es könnte
z.B. vorteilhafter Weise der von Ericsson verfügbare Mobile Internet Enabling
Proxy 1.0 sein. Die Kommunikation zwischen dem Zwischengerät 20 und dem
Web-Server 30 wird durch das HTTP-Protokoll bestimmt. Der
Web-Server 30 verarbeitet
somit HTTP-Anforderungen und teilt Antworten aus und es wird auch
auf ihn als einen HTTP-Server verwiesen. Der mit der Erfindung verwendete
Server kann einen weiten Bereich von Funktionalitäten implementieren
und kann z.B. eine MMSC sein.
-
Immer
noch mit Verweis auf 5 sendet das Client-Endgerät 10 eine
GET-Anforderung, für
eine Ressource an einem durch den Uniform Ressource Locator (URL)
spezifizierten Standort fragend, an den Proxy 20, welcher
die HTTP-Nachricht an den angeforderten Web-Server 30 in
konventioneller Weise weiterleitet. Wenn einem Fehler begegnet wird,
gibt der Server 30 einen ersten HTTP-Fehlerstatuscode (500
in dem Beispiel von 5) an den Proxy 20 aus.
Gemäß der Erfindung
transformiert der Proxy 20 dann diesen ersten Fehlerstatuscode
in eine Fehlerbeschreibungsnachricht, die einen Fehlerbeschreibungstext 24 und
einen zweiten Statuscode (200 in dem Beispiel von 5)
umfasst, bevor die Nachricht an das Client-Endgerät 10 übermittelt
wird.
-
Der
Fehlerbeschreibungstext 24 ist ein Text beliebiger Länge, der
die Fehlersituation dem Endbenutzer erläutert. Er ist vorzugsweise
als eine Seite der Wireless Markup Language (WML) oder der Hypertext
Markup Language (HTML) implementiert. Der Fehlerbeschreibungstext
darf somit nicht mit der optionalen und sehr eingeschränkten Grundphase
durcheinander gebracht werden, die, wie in dem Hintergrundabschnitt
erwähnt,
manchmal den Fehlerstatuscode in der Startzeile einer HTTP-Nachricht
begleitet.
-
Der
zweite Statuscode dient dazu, sicherzustellen, dass der Fehlerbeschreibungstext 24 bei
dem Client-Endgerät 10 angezeigt
wird. Vorzugsweise bildet ein HTTP-Statuscode des 2XX-Formats, wie
beispielsweise der 200-Code, den zweiten Statuscode der Erfindung,
da diese Codes "Erfolg" bedeuten, und somit
implizieren, dass ein angehängtes
Dokument immer gezeigt wird. Somit wird garantiert, dass eine zusammen
mit dem 200-Statuscode gesendete Fehlerbeschreibungsseite dem Endbenutzer
präsentiert
wird.
-
Die
vorliegende Erfindung verwendet somit einen Statuscode, der nicht
einen Fehler angeben muss, sondern stattdessen eine positive Antwort
zum Durchsetzen bzw. Erzwingen einer Anzeige des gewünschten Fehlerbeschreibungstextes
bei dem Client-Endgerät ausmachen
könnte.
Auf diese Weise steuert der Mobiloperator sowohl den eigentlichen
Beschreibungstext der Fehlernachricht als auch die Darstellung davon
und kann eine erzwungene Anzeige irgendeines gewünschten Erläuterungstextes für den Endbenutzer
erreichen.
-
Die
Fehlernachricht-Transformation wird vorzugsweise mittels einer Fehlerinformationstabelle 22 implementiert.
Wie in 6 veranschaulicht werden der erste Fehlerstatuscode
und vorzugsweise auch die URL der HTTP-Anforderung an die Tabelle
22 eingegeben. Basierend auf dieser Eingabeparameterinformation
werden der zweite Statuscode und die Fehlerseite mit dem Fehlerbeschreibungstext 24 bereitgestellt.
Es wird bevorzugt, dass die URL an die Fehlerinformationstabelle 22 eingegeben
wird, da dieses ermöglicht,
dass Ressourcenstandort-abhängige
Fehlerbeschreibungsnachrichten ausgegeben werden.
-
Die
Fehlerinformationstabelle 22 wird vorzugsweise in der Proxy-Software
implementiert. Jedoch liegen auch Ausführungsformen in dem Bereich
der Erfindung, wo der Proxy eine externe Fehlerinformationstabelle
abruft.
-
Tabelle
1 umreißt
die Struktur einer Fehlerinformationstabelle gemäß einer bevorzugten Ausführungsform
der Erfindung. Sie enthält
eine Anzahl von Beispielsfällen,
wo Eingabeparameter in der Form eines ersten Fehlerstatuscodes und
des Servers der URL in eine Fehlerbeschreibungsnachricht transformiert
werden. Die Fehlerbenachrichtigungsnachricht basiert auf Ausgabeparametern,
die einen zweiten Statuscode und eine Fehlerseite mit einem Fehlerbeschreibungstext
umfassen. Die Sprache jeder Fehlerseite ist vorzugsweise in der
Tabelle definiert.
-
-
-
Man
betrachte z.B. eine Anforderung mit einer URL, die auf einen bestimmten
Web-Server S1 zeigt, der sich außerhalb der Steuerung des Mobiloperators
befindet. Solch eine Anforderung würde, wenn sie einem HTTP-Fehler
mit Statuscode 500 unterworfen wird, gemäß Tabelle 1 darin resultieren,
dass der Proxy eine WML-Seite mit einem geeigneten Fehlerbeschreibungstext
T1 zusammen mit dem neuen Statuscode 200 an das Client-Endgerät sendet.
Der Statuscode 200 für "Erfolg" garantiert, dass
der Fehlerbeschreibungstext dem Endbenutzer präsentiert wird.
-
Tabelle
1 implementiert die erwähnte
bevorzugte Verwendung der URL-Dienst-Standortinformation durch den
Proxy zum Bereitstellen von Ressourcenstandort-abhängigen Fehlernachrichten.
Eine wichtige Unterscheidung hierbei ist zwischen externen Web-Servern
und Servern innerhalb der Steuerungsreichweite des Mobiloperators.
Manchmal kann ein mit einem Operator für einen Web-Server verknüpfter Fehlercode
nicht einmal als begründend
für einen
erweiterten Fehlerbeschreibungstext betrachtet werden, sondern vielmehr den
Proxy unverändert
passieren (siehe das Beispiel mit Statuscode 501). Darüber hinaus
werden unterschiedliche externe Web-Server typischer Weise unterschiedlich
behandelt. Zum Beispiel haben die Fälle von Server-URL S1, S2 und
S3 alle denselben Eingangsstatuscode (500). Nichtsdestotrotz werden
unterschiedliche Fehlerbeschreibungstexte T1, T2 und T3 ausgegeben,
abhängig
von dem jeweiligen Dienststandort. Diese fallspezifischen Fehlerbeschreibungstexte
enthalten zweifelsohne detailliertere Erläuterungen einer jeweiligen Fehlersituation,
als sie andernfalls möglich
sein würde.
-
Ein
Beispiel in Tabelle 1 betrifft den Fall, wo der Web-Server eine
durch den Mobiloperator gesteuerte MMSC ist. Dieses ist auch in 7 veranschaulicht,
welche ein schematisches Blockdiagramm eines beispielhaften Fehlerbenachrichtigungssystems
für eine
MMS-Kommunikation gemäß der Erfindung
ist. Die Fehlerbeschreibungsnachricht umfasst nun vorzugsweise eine
neue MMS-Nachricht 24 mit dem gewünschten Fehlerbeschreibungstext.
In dem Fall gelöschter
MM3-Nachrichten (beschrieben mit Verweis auf 4) würde der Feflerbeschreibungstext
typischer Weise den Endbenutzer informieren, dass die Nachrichten
entfernt worden sind, und würde
vorzugsweise eine Erläuterung
dafür enthalten.
Das MMS-Paket 24 wird
an den MMS-Browser des Client-Endgerätes 10 gesendet, wo
es in eine WML- oder HTML-Seite umgewandelt wird, was eine Anzeige
des Beschreibungstextes ermöglicht.
-
Der
von der MMSC 30 in 7 gesendete
erste Statuscode 404 ist ein Beispiel. Es könnte irgendein HTTP-Fehlerstatuscode
sein, wie beispielsweise ein anderer 4XX-Code. Ähnlich kann irgendein 2XX-Code oder
ein anderer mit einer zwangsweisen Dokumentenpräsentation verknüpfter Statuscode
den zweiten Statuscode in einem bevorzugten MMS-Kommunikationssystem
ersetzen.
-
In 7 wird
die MMS-Fehlernachricht 24 erzeugt und von dem Proxy 20 übermittelt.
Obwohl dieses die bevorzugte Implementierung ist, kann es Situationen
geben, wo anstatt die neue MMS-Nachricht durch die MMSC erzeugt
wird, wie in 8 veranschaulicht. Der Fehlerbeschreibungstext
wird dann, möglicherweise zusammen
mit einem oder mehreren Bildern, in der MMSC 30 gepackt,
um die neue MMS-Nachricht 24 gemäß dem MMS-Standard zu bilden.
Der Fehlerbeschreibungstext kann entweder durch ein Textdokument
oder ein Bilddokument in der MMS-Nachricht 24 implementiert
werden. Die neue MMS-Nachricht 24 mit dem Fehlerbeschreibungstext
wird von der MMSC 30 zusammen mit einem HTTP-Statuscode
für einen
Erfolg gesendet, z.B. den 200-Code. Da der Proxy 20 nun
glaubt, dass die GET-Anforderung
erfolgreich war, leitet er bloß die
Fehlernachricht an das Client-Endgerät 10 weiter. Wie zuvor
wird das MMS-Paket 24 an den MMS-Browser des Client-Endgerätes 10 gesendet,
wo es in eine WML- oder HTML-Seite umgewandelt wird, was eine Anzeige des
Fehlerbeschreibungstextes ermöglicht.
-
Obwohl
die veranschaulichten Beispiele das Anforderungsverfahren GET betreffen,
sollte verstanden werden, dass die Erfindung auch auf andere HTTP-Anforderungsverfahren
anwendbar ist, einschließlich
des POST-Verfahrens. Ein Fachmann wird erkennen, dass die hier angeführten Fehlercodenummern
Beispiele sind, und dass die Erfindung für andere HTTP-Fehlercodes verwendet
werden kann.
-
9 ist
ein Flussdiagramm einer beispielhaften Ausführungsform eines bevorzugten
Verfahrens eines Handhabens von Fehlernachrichten gemäß der Erfindung.
Die Prozedur wird bei einer HTTP-Anforderung von einem drahtlosen
Client-Endgerät eingeleitet.
In einem Schritt S1 wird ein erster Statuscode, welcher ein HTTP-Fehlerstatuscode
von einem Server ist, bei einem Zwischengerät, z.B. einem Proxy, empfangen.
Der erste Statuscode wird in einem Schritt S2 durch das Zwischengerät in eine
Fehlerbeschreibungsnachricht transformiert, die einen Fehlerbeschreibungstext
als auch einen zweiten Statuscode enthält. Schritt S2 umfasst vorzugsweise
ein Extrahieren der Fehlerbeschreibungsnachricht aus einer Fehlerinformationstabelle
in Ansprechen auf eine Eingabeparameterinformation, die den ersten
Statuscode und den URL-Server enthält. Dadurch werden Ressourcenstandortabhängige Fehlerbeschreibungsnachrichten
erhalten. In einem Schritt S3 übermittelt
das Zwischengerät
die Fehlerbeschreibungsnachricht, die eine WML-Seite, eine HTML-Seite oder eine MMS-Nachricht
umfasst, die den Fehlerbeschreibungstext zu dem Client-Endgerät trägt. Eine
Anzeige des Fehlerbeschreibungstextes für den Endbenutzer wird durch
die Natur des zweiten Statuscodes in einem letzten Schritt S4 erzwungen.
Die Prozedur erreicht somit eine garantierte Präsentation irgendeines gewünschten
Fehlerbeschreibungstextes.
-
Obwohl
die Erfindung mit Verweis auf spezifische veranschaulichte Ausführungsformen
beschrieben worden ist, soll hervorgehoben werden, dass sie auch Äquivalente
zu den offenbarten Merkmalen abdeckt, als auch einem Fachmann offensichtliche
Modifikationen und Varianten. Somit wird der Bereich der Erfindung
nun durch die beigefügten
Ansprüche
beschränkt.
