2010-06-08 7 views
0

Ceci provient de la RFC POP3.Question sur l'octet de terminaison de message POP3

« Les réponses à certaines commandes sont multi-ligne. Dans ces cas, qui sont clairement indiqués ci-dessous, après l'envoi de la première ligne de la réponse et un CRLF, des lignes supplémentaires sont envoyés, chaque terminaison par un Paire CRLF Lorsque toutes les lignes de la réponse ont été envoyées, une ligne finale est envoyée, composée d'un octet de terminaison (code décimal 046, ".") Et d'une paire CRLF Si une ligne de la réponse multi-ligne commence par l'octet de terminaison, la ligne est "remplie d'octets" par en attente de l'octet de terminaison à cette ligne de la réponse Par conséquent, une réponse multiligne est terminée avec les cinq octets "CRLF.CRLF". Lors de l'examen d'une réponse multiligne, le client vérifie pour voir si la ligne commence par l'octet de terminaison. Si c'est le cas et si octets autres que CRLF suivent, le premier octet de la ligne (l'octet de terminaison ) est supprimé. Si oui et si CRLF immédiatement suit le caractère de fin, la réponse du serveur POP est terminée et la ligne contenant « .CRLF » n'est pas considéré une partie de la réponse à plusieurs lignes. »

Eh bien, J'ai problème avec cela, par exemple gmail envoie parfois l'octet de terminaison, puis dans la ligne suivante envoie la paire CRLF par exemple:.

"+OK blah blah\r\n" 
"blah blah.\r\n" 
"\r\n" 

C'est très rare, mais il arrive parfois, si évidemment je ne suis pas pour déterminer la fin du message dans ce cas, parce que j'attends une ligne qui se compose de '. \ r \ n'. Sérieusement, est Gmail violer le protocole POP3 ou je fais quelque chose de mal? Aussi j'ai une deuxième question, l'anglais n'est pas ma langue première donc je ne peux pas comprendre cela complètement:

"Si n'importe quelle ligne de la réponse de multi-ligne commence par l'octet de terminaison, la ligne est" byte-bourré "par pré-en attente de l'octet de terminaison à cette ligne de la réponse Par conséquent, une réponse multi-ligne est terminée avec les cinq octets "CRLF.CRLF". "

Quand exactement CRLF.CRLF est utilisé? Quelqu'un peut-il me donner un exemple simple? Le rfc dit que c'est utilisé quand n'importe quelle ligne de la réponse commence avec l'octet de terminaison. Mais je ne vois aucune ligne commençant par '.' dans les messages qui sont terminés avec CRLF.CRLF. J'ai vérifié ça. Peut-être que je ne comprends pas quelque chose, c'est pourquoi je demande.

+0

Cela n'a aucun sens. Comment pouvez-vous avoir une «ligne suivante», sauf si elle est causée par une paire CR, LF? Je pense que le problème doit être dans votre routine de socket de lecture. Êtes-vous en train de vérifier EAGAIN? –

+0

Je ne suis pas sûr de ce que vous voulez dire.Ce ne sont pas les lignes dans le message réel, de manière évidente les lignes dans le message réel sont terminées délimitées avec la paire CRLF, mais l'exemple que j'ai donné est composé des différentes réponses du serveur. Bien, bien sûr, le RFC POP3 dit qu'ils sont terminés avec la paire CRLF mais ils ne le sont pas, au moins Gmail ne le fait pas. – user361633

Répondre

2

Il serait très utile si vous avez publié le code que vous utilisez pour lire le socket. Mais je vais tenter de répondre à la deuxième partie de votre question avec cet exemple:

Si la réponse est:

hello world\r\n 
we are doing fine\r\n 
.500 is same as one-half\r\n 
this is the last line\r\n 

le serveur doit envoyer comme:

hello world\r\n 
we are doing fine\r\n 
..500 is same as one-half\r\n 
this is the last line\r\n 
.\r\n 

vous pouvez donc voir où 'byte bourré' un extra '.' donc le '.500' peut être distingué dans le cadre de la réponse. Les cinq derniers octets sont également '\ r \ n. \ R \ n'.