Nitpicking and Flyspecking: Minor glitches in the book's simple HTML server

I know these are out of the book's scope, but since they might surprise users they might be worth mentioning:

  1. Some browser fetches/refreshes (from Firefox) are sending two requests rather than one. The second request seems to be a fetch for "/favicon.ico", which I believe is the optional website icon. I'm not sure whether the book mentions that additional "helper" requests may be sporadically sent by some clients. I know, the goal isn't to teach HTTP, but it might be good to reassure students that this is a fairly normal behavior.

  2. Occasionally, I will get a panic:

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', src/

This is from the `handle_connection+ line fetching the request URI:

    let request_line=buf_reader.lines().next().unwrap().unwrap(); //Option<Result>

This tends to happen on one of the early fetches after starting this simple server, and I haven't yet seen it happen a second time. Oddly, it seems to hit Worker 3 more often than the others. It does crash that thread, of course. If this is a not-unusual behavior, the book might (or might not) want to mention this and point out that this is a good example of why you don't want to let panic()s happen; even if they don't crash the whole program they may result in loss of threads, which may cause other unexpected behavior.

Also, as I get deeper into the code, I find that when I enter the incremental "should not compile yet" solutions, they are sometimes not producing the expected errors.

Most recent example: I've just added the initial stub for impl Drop for ThreadPool. The doc tells us to expect error[E0507] because JoinHandle<()> does not implement the Copy trait. But I'm not seeing any complaint, just the warnings about unused fields.

I am guessing that these "non-errors" are because the Rust library has changed and the types now implement traits which they didn't when the book was last edited. But I haven't probed to check that.

Probably not a serious problem, but it may confuse readers when their own compilation doesn't produce the expected error.

Alas, I haven't been keeping a list of these divergences, but I know I've seen one or two others recently -- this chapter or the ones preceding it.

(Exact wordings of error/warning messages have also changed since the book was last updated. Even nitpickier; I wouldn't worry about it until/unless the next full review pass.)

I tried copying the code from that section of the book to the playground and I get the expected error: Rust Playground

Maybe you expected that

impl Drop for ThreadPool {
    fn drop(&mut self) {
        // todo

should cause the error? But the trait impl itself isn't the problem, only its contents.

Hmm. Perhaps I didn't copy it identically, or some other change I'd made along the way interacted in an unexpected manner... Sigh. When I get a chance I'll try to reproduce. Until then, feel free to blame the loose nut behind the keyboard.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.