If I may pipe in, in my opinion this is strictly a failure of the logging mechanism, and the HTTP implementation (regardless of whether control characters are allowed or not allowed) is irrelevant. If data is being logged, that data should be logged unambigously, in a manner suitable for retrieval, and should be retrieved by an appropriate agent. If the logging mechanism cannot reliably or safely log some bytes, then something should be changed (I don't care what) so that those bytes are not logged. Very simple. The log format that fails to escape double quotes is a good example of an ambiguous logging format, and using cat or more (as opposed to less in non-raw mode) is a good example of using an improper log review mechanism. (The log is the place where concentrated evil is stored. Why would you feed that directly to your terminal? Do you know what back doors are in your terminal emulation code?) More constructively, how about changing the logging library used here so that is smart enough to reformat control characters safely and unambiguously (perhaps ^A => \01, ^B => \02, \ => \\, or something similar) and if the output of quoted strings is necessary, some method of telling it to escape the quotes used for a particular string. However, there is one trick available that can help decode strings with embedded quotes: if there is only _one_ such string in a block of data, and the end of the data is known with precision, just scan backwards from the end for the unambiguous last quote, and forwards from the beginning for the unambiguous first quote. -- Kenneth Albanowski (kjahdsat_private, CIS: 70705,126)
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:28:16 PDT