[dovecot-cvs] dovecot/src/lib-storage/index index-fetch-section.c,1.25,1.26

[cras at procontrol.fi]

Update of /home/cvs/dovecot/src/lib-storage/index
In directory danu:/tmp/cvs-serv10289/lib-storage/index

Modified Files:
	index-fetch-section.c 
Log Message:
The ending \r\n is message header shouldn't be filtered with FETCH
BODY[HEADER.FIELDS...].



Index: index-fetch-section.c
===================================================================
RCS file: /home/cvs/dovecot/src/lib-storage/index/index-fetch-section.c,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -d -r1.25 -r1.26
--- index-fetch-section.c	22 Dec 2002 08:23:01 -0000	1.25
+++ index-fetch-section.c	2 Jan 2003 12:20:46 -0000	1.26
@@ -188,12 +188,13 @@
 	FetchHeaderFieldContext *ctx = context;
 	const char *field_start, *field_end, *cr, *p;
 
-	/* see if we want this field */
+	/* see if we want this field. */
 	if (!ctx->match_func(ctx->fields, name, name_len))
 		return;
 
 	/* add the field, inserting CRs when needed. FIXME: is this too
-	   kludgy? we assume name continues with ": value".. */
+	   kludgy? we assume name continues with ": value". but otherwise
+	   we wouldn't reply with correct LWSP between ":". */
 	field_start = name;
 	field_end = value + value_len;
 
@@ -241,6 +242,12 @@
 
 	ctx->dest_size = 0;
 	message_parse_header(NULL, input, NULL, fetch_header_field, ctx);
+
+	/* FIXME: The blank line must not be filtered, says RFC. However, we
+	   shouldn't add it if it wasn't there in the first place. Not very
+	   easy to know currently so we'll just do it always, it'll be present
+	   in all sane messages anyway.. */
+	(void)fetch_header_append(ctx, "\r\n", 2);
 
 	i_assert(ctx->dest_size <= ctx->max_size);
 	i_assert(ctx->dest == NULL || str_len(ctx->dest) == ctx->dest_size);