Today, I spent some time staring at an old piece of code that I had written at least a year ago. It’s been in testing several times, but never put into production (the project it is tied to has been bumped on several occaisions). Today, it was back in testing.<\/p>\n
The code is a failry simple web service, written in Perl. I like Perl. I have no illusions that I’m a fantastic Perl hacker, but I know the language well, though both experience and reading. I’ve read most of the O’Reilly Perl titles, including Programming Perl<\/a> (“The Camel”), which I’ve read cover to cover at least three times. I still find myself looking things up, usually to refresh my memory about something I can remember reading, or some syntax detail I can’t get right (one of the perils of working in multiple languages). At least I generally know where to look.<\/p>\n So this web service has been tested before. It works in a browser, and it works when called by my test client. It’s been tested with a third-party bit of code. Today, it was tested by Dave<\/a>, using some custom client code he had written in C#. And it worked… if<\/em> he told his http library to ignore HTTP protocol errors. If he didn’t, his library complained.<\/p>\n And so I stared at the code for a while. By coincidence, I’d been reading the HTTP Spec<\/a> over the weekend (yes, I’m a geek), and was pretty sure my response was good- a bare-minumum response, along the lines of:<\/p>\n I double checked the spec anyway, and kept staring at the code. I was about to start grasping at straws and adding additional entity headers to the response (such as Content-Length), when I finally stared at the code long enough. I saw something like this:<\/p>\n Then it hit me- And there my tale should end. But this evening, I started wondering if the octal sequence was the most Perlish way to send a CRLF. I knew that Turns out the manpage specifically recommends the octal form for networking applications (at least I got that right), but then it twists the knife:<\/p>\n If you get in the habit of using D’oh.<\/p>","protected":false},"excerpt":{"rendered":" Today, I spent some time staring at an old piece of code that I had written at least a year ago. It’s been in testing several times, but never put into production (the project it is tied to has been bumped on several occaisions). Today, it was back in testing. The code is a failry […]<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[13],"tags":[],"class_list":["post-307","post","type-post","status-publish","format-standard","hentry","category-perl"],"_links":{"self":[{"href":"https:\/\/jclark.org\/weblog\/wp-json\/wp\/v2\/posts\/307","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/jclark.org\/weblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/jclark.org\/weblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/jclark.org\/weblog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/jclark.org\/weblog\/wp-json\/wp\/v2\/comments?post=307"}],"version-history":[{"count":0,"href":"https:\/\/jclark.org\/weblog\/wp-json\/wp\/v2\/posts\/307\/revisions"}],"wp:attachment":[{"href":"https:\/\/jclark.org\/weblog\/wp-json\/wp\/v2\/media?parent=307"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/jclark.org\/weblog\/wp-json\/wp\/v2\/categories?post=307"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/jclark.org\/weblog\/wp-json\/wp\/v2\/tags?post=307"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}HTTP\/1.1 200 OK\nContent-Type: text\/plain; charset=utf-8\n\nSingle Line Response<\/code><\/pre>\nprint "HTTP\/1.1 $status\\n"\nprint "Content-Type: text\/plain; charset=utf-8\\n"<\/code><\/pre>\n"\\n"<\/code> in perl is a “magic newline”- it conforms to the newline convention on the system in question. HTTP, on the other hand, requires ASCII CR+LF (Cariage Return + Line Feed, or "\\r\\n"<\/code> in C) as a line terminator. Apparently all of the code thrown at the service before today was a bit forgiving. I changed the strings to send CRLF using octal escape sequences ("\\015\\012"<\/code>), and everything was fine. I was a bit ticked about the mistake… I new both the HTTP requirement for CRLF and the Perl treatment of "\\n"<\/code> when I originally wrote the code; it was a dumb mistake. Also aggravating that it took so long to spot.<\/p>\n"\\r"<\/code> is fine for the CR, but you can’t use "\\n"<\/code> for the LF – it’s magic in perl, and behaves differently on different platforms. I began to wonder if Perl has a backslash-escape for LF that is always<\/em> LF. Eventually, I had to check for myself, so I referred to the Quote and Quote-like Operators<\/a> section of the perlop man page. (Sadly, I knew right where to look, right down to the name of the section. Geek, remember?)<\/p>\n\n
"\\n"<\/code> for networking, you may be burned some day.<\/p>\n<\/blockquote>\n