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

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 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?

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)

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:

1

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

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).

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

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

Tschüß