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

tutorials
1

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/main.rs:42:48

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.

2

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.)

3

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.

4

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.

5

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.