Author Lukasa
Recipients Lukasa, barry, demian.brecht, icordasc, martin.panter, mgdelmonte, r.david.murray
Date 2015-06-03.08:21:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1433319694.45.0.14236085819.issue24363@psf.upfronthosting.co.za>
In-reply-to
Content
> It is obvious that this case could be treated as a folded (continuation) line. But in general I think it would be better to ignore the erroneous line, or to record it as a defect so that the server module or other user can check it.

Just to clarify, in an instance very similar to this one this would be *terrible* advice. The token that would be lost here is the 'Secure' field on the cookie, which is an extremely important token to have: if we don't correctly parse it, we run the risk of sending the cookie on plaintext connections.

Discarding data is the problem, and while discarding *less* data is an improvement, it would be good if we could resolve this problem in such a way that we'd have correctly parsed this header.

Generally speaking, if we treat these as continuation lines I think we have the best change of making a useful header out of this mess.
History
Date User Action Args
2015-06-03 08:21:34Lukasasetrecipients: + Lukasa, barry, r.david.murray, martin.panter, icordasc, demian.brecht, mgdelmonte
2015-06-03 08:21:34Lukasasetmessageid: <1433319694.45.0.14236085819.issue24363@psf.upfronthosting.co.za>
2015-06-03 08:21:34Lukasalinkissue24363 messages
2015-06-03 08:21:33Lukasacreate