HTTP - Header Encoding

[Gerhard]

Hallo allerseits,

mit ist nicht ganz klar, wie bei einem HTTP Request / Response das Encoding des Message Headers herausgefunden werden kann.
Mit "Content-Type: text/html; charset=utf-8" kann man ja nur das Encoding des Contents erhalten/festlegen.
Wenn nun aber beispielsweise  "Authorization" im HTTP Header angegeben wird, so wird unter Umstaendern ja auch Username/Password mitgeschickt. In welchem Encoding sind denn nun der Username/Password  ?

Danke,
Gerhard

[Rolf Rost]

hi,

Wenn nun aber beispielsweise  "Authorization" im HTTP Header angegeben wird, so wird unter Umstaendern ja auch Username/Password mitgeschickt. In welchem Encoding sind denn nun der Username/Password  ?

Base64 wenn ich mich nicht irre ;-)

Rolf

[Gerhard]

ich meinte eigentlich nicht , in welchem CHARACTER Encoding (ISO-8859, UTF-8, Shift-JIS)

Gerhard

[Calocybe]

Moin!

mit ist nicht ganz klar, wie bei einem HTTP Request / Response das Encoding des Message Headers herausgefunden werden kann.
Mit "Content-Type: text/html; charset=utf-8" kann man ja nur das Encoding des Contents erhalten/festlegen.

Zunaechst mal: Der Begriff "Encoding" bezieht sich in HTTP darauf, wie (bzw. ob) der Inhalt nochmal zusaetzlich irgendwie anders dargestellt wird. Das gaengigste Encoding ist "gzip", mit dem Inhalte komprimiert transportiert werden, also auch ganz normale HTML-Files. Der Browser, der das Encoding verstehen muss, macht das Encoding noch vor jeder weiteren Verarbeitung rueckgaengig, im Fall von gzip wird der Inhalt also "entpackt".

Was Du meinst ist ganz einfach der Zeichensatz, der im Content-Type mit angegeben wird. (In anderen Zusammenhaengen ist dafuer das Wort "Encoding" durchaus richtig.)

Sowohl fuer das Encoding als auch den Zeichensatz gilt, dass sich diese nicht auf die HTTP-Header beziehen, sondern immer nur auf den transportierten Inhalt (also gewoehnlich das uebertragene HTML-Dokument).

Wenn nun aber beispielsweise  "Authorization" im HTTP Header angegeben wird, so wird unter Umstaendern ja auch Username/Password mitgeschickt. In welchem Encoding sind denn nun der Username/Password  ?

Ich hab mir jetzt mal ein paar RFCs reingezogen und muss sagen, dass ist beim ersten Lesen nicht ganz einfach zu durchschauen, daher will ich folgendes nicht als verbindliche Information verkaufen. Das RFC-Paar 2616/2617 schreibt:

basic-credentials = base64-user-pass
  base64-user-pass  = <base64 encoding of user-pass, except not limited to 76 char/line>
  user-pass   = userid ":" password
  userid      = *<TEXT excluding ":">
  password    = *TEXT

TEXT        = <any OCTET except CTLs, but including LWS>
  OCTET       = <any 8-bit sequence of data>
  CTL         = <any US-ASCII control character (octets 0 - 31) and DEL (127)>
  LWS         = [CRLF] 1*( SP | HT )
  CRLF        = CR LF
  CR          = <US-ASCII CR, carriage return (13)>
  LF          = <US-ASCII LF, linefeed (10)>
  SP          = <US-ASCII SP, space (32)>
  HT          = <US-ASCII HT, horizontal-tab (9)>

und notiert (unter anderem) dazu:

"The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT MAY contain characters from character sets other than ISO-8859-1 only when encoded according to the rules of RFC 2047."

In RFC 2047 ist dann beschrieben, wie einzelne Woerter in einem Zeichensatz kodiert werden koennen. Das ist das, was man im Sourcetext von EMails sehen kann, wenn man im Subject oder im Absendernamen z.B. Umlaute verwendet. Sieht ungefaehr so aus:
  =?ISO-8859-1?Q?Andr=E9?= Pirard
Das =E9 steht hier fuer das Zeichen, welches in HTML mit é niedergeschrieben wird. Das ist die Kodierung als "quoted printable". Das Q zwischen den zwei Fragezeichen steht fuer diese Art der Kodierung. Ausserdem waere an dieser Stell schon die Base64-Codierung moeglich (aber unabhaengig vom Base64 fuer user-pass); statt Q muesste dann ein B stehen.

Insgesamt fasse ich das also so auf: Wenn die Username/Passwoerter in ISO-8859-1 geschrieben sind, kein Problem, einfach mit ":" aneinanderkleben, base64 drueber und dann ab die Post. Werden andere Zeichen verwendet, die in Latin1 nicht vorkommen, muss man diese zunaechst *separat* entsprechend RFC 2047 als quoted printable oder base64 kodieren, dann mit ":" zusammenkleben, und dann (nochmal) base64-kodieren. Die Dekodierung geht dann entsprechend umgekehrt. Das ist sicher sehr lustig, wenn man dann Passwoerter in Shift-JIS reinkriegt. *g* Und ich frage mich, wieviele Browser diese Kodierung korrekt vornehmen...

Na dann viel Spass!

So long

[Michael Schröpl]

Hi Calocybe,

Das gaengigste Encoding ist "gzip", mit dem Inhalte komprimiert transportiert werden,

Dein Wort in das Ohr der Administratoren - leider ist das gängigste Encoding ganz offensichtlich immer noch "identity" ... :-(

basic-credentials = base64-user-pass
  base64-user-pass  = <base64 encoding of user-pass, except not limited to 76 char/line>

Das gilt für die Authorisationsmethode "Basic" (das, was man im Apache mit "AuthType" einstellt) - bei "Digest" gilt beispielsweise eine andere 'Codierung'.

Viele Grüße
      Michael

[Calocybe]

Moin!

Dein Wort in das Ohr der Administratoren - leider ist das gängigste Encoding ganz offensichtlich immer noch "identity" ... :-(

Aeh ja, das gaengigste abgesehen von identity.

Das gilt für die Authorisationsmethode "Basic" (das, was man im Apache mit "AuthType" einstellt) - bei "Digest" gilt beispielsweise eine andere 'Codierung'.

Ja, ich dachte, dass es nur darum ging. Falls es auch um die Digest-Methode geht, habe ich quasi eine Anleitung zum Selbstrecherchieren gegeben. ;-)

So long

[Gerhard]

Hi,

Ich bin nun um einiges gescheiter geworden und werde mich, nachdem ich  weiss, wo ich anfangen kann, genauer mit dem Thema befassen. Waer doch gelacht, wenn man nicht heausbekommt, in welchem character-encoding user/pwd uebertragen werden.

Gruesse,
Gerhard