Protokoll beendet die Übertragung mit CRLF - was wenn der Chunk CRLF enthält?

[Lolle (Gast)]

Hi,

der Titel sagt eigentlich schon alles... :-) Ein Protokoll (in meinem 
Fall IRC, aber ist auch z.B. bei HTTP oder IMAP so) beendet eine 
Datenübertragung mit CRLF und signalisiert so das Ende.

Falls die Übertragung so groß ist, dass sie in einzelne Chunks 
aufgeteilt ist: was, wenn der Chunk CRLF enthält? Wie kann die 
Clientseite dann unterscheiden zwischen CRLF im Chunk oder CRLF am Ende 
der Datenübertragung?

Danke!

[Udo S. (urschmitt)]

Indem man Meta Zeichen definiert:
Wie z.B. der Backslash bei C Strings.

ein cr ist dann halt ein \r
ein nl ist ein \n
ein '\' ist ein \\

[Lolle (Gast)]

Udo Schmitt schrieb:
> Indem man Meta Zeichen definiert:
> Wie z.B. der Backslash bei C Strings.
>
> ein cr ist dann halt ein \r
> ein nl ist ein \n
> ein '\' ist ein \\

Was meinst du mit "indem man"? Da kommen am Socket innerhalb einer 
einzigen Übertragung de facto mehrere CRLF an. Eins davon zwar ganz 
hinten, aber was, wenn mal die Buffergröße genau so liegt, dass eines 
der inneren CRLF am Ende sitzt?

[Udo S. (urschmitt)]

Redest du jetzt von einem eigenen Protokoll, oder von schon 
existierenden? Wenn das ein schon existierendes ist, dann muss das 
Protokoll Vorkehrungen besitzen daß diese Zeichen transparent übertragen 
werden können, zum Beispiel durch Metazeichen, oder diese 
(Steuer)Zeichen sind schlicht und einfach VERBOTEN!

[Lolle (Gast)]

Udo Schmitt schrieb:
> Redest du jetzt von einem eigenen Protokoll, oder von schon
> existierenden? Wenn das ein schon existierendes ist, dann muss das
> Protokoll Vorkehrungen besitzen daß diese Zeichen transparent übertragen
> werden können, zum Beispiel durch Metazeichen, oder diese
> (Steuer)Zeichen sind schlicht und einfach VERBOTEN!

Hi, ich rede von einem bereits existierenden, von IRC. Siehe ganz oben:

Lolle schrieb:
> [...] Ein Protokoll (in meinem Fall IRC [...]

Aber es ist eben auch z.B. bei HTTP so. Da kommt als letztes Zeichen 
einfach CRLF und im HTML-Code ist CRLF ja wohl nicht kodiert.

Oder übersehe ich irgendwas?

[bluppdidupp (Gast)]

Das Ende einer HTTP-Message wird entweder einfach durch schließen der 
Verbindung mitgeteilt oder weil im HTTP-Header durch das Feld 
"Content-Length" die Länge der Nutzdaten bekannt sind.
Im Falle von chunked-transfer-encoding ist das Ende durch den letzten 
chunk, welcher immer Länge 0 hat auch bekannt.

CRLF ist bei HTTP eigentlich nur relevant, um das Ende eines Headers zu 
ermitteln (das Ende eines Headers wird durch zwei direkt 
aufeinanderfolgende (CR)LF markiert)

[Udo S. (urschmitt)]

Ok blubbdiblubb war schneller, weil ich erst mal schauen musste.
Und beim http Request ist das \n\r ein Steuerzeichen und in dem 
Datenteil schlichtweg VERBOTEN.

IRC kenne ich nicht, da musst du einfach mal suchen und lesen

[Udo S. (urschmitt)]

Habe mal nachgeschaut:
In RFC 1459 findet sich zum Beispiel:

IRC messages are always lines of characters terminated with a CR-LF
   (Carriage Return - Line Feed) pair, and these messages shall not
   exceed 512 characters in length, counting all characters including
   the trailing CR-LF. Thus, there are 510 characters maximum allowed
   for the command and its parameters.  There is no provision for
   continuation message lines.  See section 7 for more details about
   current implementations.

Also sind CR-LF in den Daten erst mal nicht erlaubt. Evt. existieren 
Definitionen von Metazeichen um trotzdem CR/LF in den Daten zu erlauben, 
aber das darfst du selbst suchen, ich mach jetzt Feierabend :-)
Die RFC findest du:
http://tools.ietf.org/html/rfc1459

[bluppdidupp (Gast)]

Bei IMAP gibt es bestimmte Formen um Strings darzustellen, für Strings 
die mit dem IMAP-Protokoll Probleme machen könnten kann man die 
"Literal"-Form nehmen, dabei wird die Länge eines Strings zusätzlich mit 
angegeben.
Das ist z.B. im wikipedia-Beispiel bei FETCH zu sehen:

12 FETCH (BODY[HEADER] {342}

...ein Client kann an der {342} erkennen, dass nun 342 Octets an 
Nutzdaten kommen, die er einfach so wegspeichern kann und garantiert 
keine IMAP-Kommandos enthalten werden, CRLFs die darin vorkommen sind 
einem IMAP-Client also egal.

Kurz gesagt: Bei IMAP sind CRLFs in Nutzdaten verboten, es sei denn man 
überträgt sie speziell formatiert ;D

[Lolle (Gast)]

bluppdidupp schrieb:
> Das Ende einer HTTP-Message wird entweder einfach durch schließen der
> Verbindung mitgeteilt oder weil im HTTP-Header durch das Feld
> "Content-Length" die Länge der Nutzdaten bekannt sind.
> Im Falle von chunked-transfer-encoding ist das Ende durch den letzten
> chunk, welcher immer Länge 0 hat auch bekannt.

Okay, klar... Das hab ich ganz vergessen. Wenn man das mit einbezieht, 
ist HTTP natürlich ein schlechtes Beispiel. ;-)

Udo Schmitt schrieb:
> Also sind CR-LF in den Daten erst mal nicht erlaubt.

Jup, ich hab das Whitepaper auch mal schon überflogen. Die CRLF, um die 
es mir geht, sind auch nicht innerhalb des PRIVMSG Commands, sondern 
z.B. in der MOTD (kommt am Anfang beim Connecten).

[Lolle (Gast)]

Und IMAP war auch ein schlechtes Beispiel... Egal, sorry. :D

[Εrnst B. (ernst)]

Lolle schrieb:
> z.B. in der MOTD (kommt am Anfang beim Connecten).

Schau in die IRC-RFC. die MOTD-Antwort wird nicht mit CRLF 
abgeschlossen, sondern durch:
":End of /MOTD command" CRLF

  - When responding to the MOTD message and the MOTD file
                  is found, the file is displayed line by line, with
                  each line no longer than 80 characters, using
                  RPL_MOTD format replies.  These should be surrounded
                  by a RPL_MOTDSTART (before the RPL_MOTDs) and an
                  RPL_ENDOFMOTD (after).

[Lolle (Gast)]

Hmm, okay. Irgendwie blöd, dass man dann gleich so viel implementieren 
muss... Aber gut, vielen Dank für eure Antworten! :-)

Tschüß