- /* Normally, this would indicate that we've read
- * as much as the server has sent us and we can
- * close the client connection. However, Microsoft
- * in its wisdom has released IIS/5 with a bug that
- * prevents it from sending the trailing \r\n in
- * a 302 redirect header (and possibly other headers).
- * To work around this if we've haven't parsed
- * a full header we'll append a trailing \r\n
- * and see if this now generates a valid one.
- *
- * This hack shouldn't have any impacts. If we've
- * already transmitted the header or if this is a
- * SSL connection, then we won't bother with this
- * hack. So we only work on partially received
- * headers. If we append a \r\n and this still
- * doesn't generate a valid header, then we won't
- * transmit anything to the client.
- */
- if (len == 0)
- {
+ /* Normally, this would indicate that we've read
+ * as much as the server has sent us and we can
+ * close the client connection. However, Microsoft
+ * in its wisdom has released IIS/5 with a bug that
+ * prevents it from sending the trailing \r\n in
+ * a 302 redirect header (and possibly other headers).
+ * To work around this if we've haven't parsed
+ * a full header we'll append a trailing \r\n
+ * and see if this now generates a valid one.
+ *
+ * This hack shouldn't have any impacts. If we've
+ * already transmitted the header or if this is a
+ * SSL connection, then we won't bother with this
+ * hack. So we only work on partially received
+ * headers. If we append a \r\n and this still
+ * doesn't generate a valid header, then we won't
+ * transmit anything to the client.
+ */
+ if (len == 0)
+ {