DE60215979T2

DE60215979T2 - Fehlermeldungsverfahren in http-gestützten kommunikationssystemen

Info

Publication number: DE60215979T2
Application number: DE60215979T
Authority: DE
Inventors: Robert Skog; Staffan Pehrson; Imre Boda
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2002-12-13
Filing date: 2002-12-13
Publication date: 2007-03-08
Anticipated expiration: 2022-12-14
Also published as: EP1574014B1; CN1708973A; WO2004084524A1; DE60215979D1; AU2002359137A1; CN100583897C; US20060236187A1; US7284160B2; JP2006510122A; HK1086136A1; EP1574014A1; JP4109258B2

Description

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.
Tabelle 1
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.

Claims

Fehlerbenachrichtigungsverfahren für ein Kommunikationssystem, in welchem ein drahtloses Client-Endgerät (10) mit einem Server (30) durch ein Zwischengerät (20) kommuniziert, mit den Schritten zum: Empfangen, bei dem Zwischengerät (20), eines ersten Hypertext Transfer Protocol (HTTP) Statuscodes von dem Server (30), wobei der erste Statuscode ein Fehlerstatuscode ist; Transformieren, bei dem Zwischengerät, des ersten Statuscodes in eine Fehlerbeschreibungsnachricht, die einen Fehlerbeschreibungstext (24) und einen zweiten HTTP-Statuscode umfasst, gekennzeichnet dadurch, dass der zweite Statuscode einen Erfolg angibt und mit einer zwangsweisen Anzeige des Fehlerbeschreibungstextes (24) bei dem Client-Endgerät (10) verknüpft ist; und Übermitteln der Fehlerbeschreibungsnachricht an das Client-Endgerät (10), wodurch die Anzeige des Fehlerbeschreibungstextes (24) bei dem Client-Endgerät (10) durch den zweiten Statuscode durchgesetzt wird.
Verfahren gemäß Anspruch 1, dadurch gekennzeichnet, dass der Transformierschritt wiederum ein Extrahieren der Fehlerbeschreibungsnachricht aus einer Fehlerinformationstabelle (22) in Ansprechen auf eine Eingabeparameterinformation mit dem ersten Statuscode umfasst.
Verfahren gemäß Anspruch 2, dadurch gekennzeichnet, dass die Eingabeparameterinformation ferner ein Uniform Resource Locator (URL) Teilstück enthält, das auf den Server (30) zeigt, und dass die extrahierte Fehlerbeschreibungsnachricht Ressourcenstandort-abhängig ist.
Verfahren gemäß einem der vorigen Ansprüche, gekennzeichnet dadurch, dass der Übermittlungsschritt durch das Zwischengerät (20) durchgeführt wird.
Verfahren gemäß einem der vorigen Ansprüche, dadurch gekennzeichnet, dass das Zwischengerät (20) aus der Gruppe einer HTTP-Proxy-Einheit und eines Wireless Application Protocol (WAP) Gateways ausgewählt wird.
Verfahren gemäß einem der vorigen Ansprüche, dadurch gekennzeichnet, dass der Server (30) eine Multimedia Messaging Service (MMS) Zentrale ist.
Verfahren gemäß Anspruch 6, dadurch gekennzeichnet, dass die Fehlerbeschreibungsschritte durch eine Client-Anforderung für eine erste MMS-Nachricht eingeleitet werden, und dass die Fehlerbeschreibungsnachricht eine zweite MMS-Nachricht umfasst.
Verfahren gemäß einem der vorigen Ansprüche, dadurch gekennzeichnet, dass der Fehlerbeschreibungstext bei dem Client-Endgerät (10) mittels einer Sprache angezeigt wird, die aus der Gruppe der Wireless Markup Language (WML) und der Hypertext Markup Language (HTML) ausgewählt ist.
Proxy-Server (20), der zwischen einem drahtlosen Client-Endgerät (10) und einem Server (30) in einem Kommunikationssystem angeordnet ist, wobei der Proxy-Server eine Fehlerbenachrichtigungseinrichtung umfasst mit: einer Einrichtung zum Empfangen eines ersten HTTP-Statuscodes von dem Server (30), wobei der erste Statuscode ein Fehlerstatuscode ist; einer Einrichtung zum Transformieren des ersten Statuscodes in eine Fehlerbeschreibungsnachricht, die einen Fehlerbeschreibungstext (24) und einen HTTP-Statuscode umfasst, gekennzeichnet dadurch, dass der zweite Statuscode einen Erfolg angibt und mit einer zwangsweisen Anzeige des Fehlerbeschreibungstextes (24) bei dem Client-Endgerät (10) verknüpft ist; und eine Einrichtung zum Übermitteln der Fehlerbeschreibungsnachricht an das Client-Endgerät (10), wodurch die Anzeige des Fehlerbeschreibungstextes (24) bei dem Client-Endgerät (10) durch den zweiten Statuscode durchgesetzt ist.
Proxy-Einheit gemäß Anspruch 9, dadurch gekennzeichnet, dass die Einrichtung zum Transformieren wiederum eine Einrichtung zum Extrahieren der Fehlerbeschreibungsnachricht aus einer Fehlerinformationstabelle (22) in Ansprechen auf eine Eingabeparameterinformation mit dem ersten Statuscode umfasst.
Proxy-Einheit gemäß Anspruch 10, dadurch gekennzeichnet, dass die Eingabeparameterinformation ferner ein URL-Teilstück enthält, das auf den Server (30) zeigt, und dass die extrahierte Fehlerbeschreibungsnachricht Ressourcenstandort-abhängig ist.
Proxy-Einheit gemäß einem der Ansprüche 9 bis 11, dadurch gekennzeichnet, dass sie aus der Gruppe einer HTTP-Proxy-Einheit und eines WAP-Gateways ausgewählt ist.
Proxy-Einheit gemäß einem der Ansprüche 9 bis 12, gekennzeichnet durch eine Einrichtung zum Kommunizieren mit einer MMS-Zentrale.
Proxy-Einheit gemäß Anspruch 13, dadurch gekennzeichnet, dass die Fehlerbeschreibungsnachricht eine MMS-Nachricht umfasst.
Proxy-Einheit gemäß einem der Ansprüche 9 bis 14, dadurch gekennzeichnet, dass der Fehlerbeschreibungstext bei dem Client-Endgerät (10) mittels einer Sprache angezeigt wird, die aus der Gruppe von WML und HTML ausgewählt ist.
Fehlerbenachrichtigungseinrichtung, die in einer MMS-Zentrale (30) angeordnet ist, die mit einem drahtlosen Client-Endgerät (10) durch einen Proxy-Server (20) kommuniziert, mit: einer Einrichtung zum Erfassen eines Fehlers, der auf eine HTTP-Anforderung von dem Client-Endgerät (10) bezogen ist; gekennzeichnet durch eine Einrichtung zum Erzeugen einer Fehlerbeschreibungsnachricht, die einen HTTP-Statuscode für einen Erfolg und eine MMS-Nachricht (24) mit einem Fehlerbeschreibungstext basierend auf dem erfassten Fehler umfasst, wobei der Statuscode mit einer zwangsweisen Anzeige des Fehlerbeschreibungstextes bei dem Client-Endgerät (10) verknüpft ist; und eine Einrichtung zum Übermitteln der Fehlerbeschreibungsnachricht an das Client-Endgerät (10) durch die Proxy-Einheit (20), wodurch die Anzeige des Fehlerbeschreibungstextes (24) bei dem Client-Endgerät (10) durch den HTTP-Statuscode für einen Erfolg durchgesetzt ist.