Inconsistent redirect behaviors for platform-specific items

[tonywu6]

Hello! I found some cases, related to platform-specific items, where docs.rs doesn't reliably redirect to the search page when the requested item doesn't exist.

(I imagine most of these only really happen if someone's writing URLs by hand. I found them while experimenting with programmatically generating links to docs.rs for my project)

• If the URL doesn't specify or specifies the default target of a crate, then docs.rs returns the blank "requested resource does not exist" page, whereas if the URL specifies a non-default target, then it redirects to search:

  • This returns 302: https://docs.rs/nix/0.31.2/aarch64-apple-ios/nix/kmod/index.html
  • This returns 404: https://docs.rs/nix/0.31.2/nix/macro.request_code_write_int.html
  • This returns 404 after a 302: https://docs.rs/nix/0.31.2/x86_64-unknown-linux-gnu/nix/macro.request_code_write_int.html
  • The corresponding target-redirect link works fine: https://docs.rs/crate/nix/0.31.2/target-redirect/nix/macro.request_code_write_int.html

• If the URL specifies a target that doesn't exist for a crate/version, then docs.rs returns 404:

  • For example: https://docs.rs/nix/0.31.2/x86_64-pc-windows-msvc/nix/kmod/index.html
  • The corresponding target-redirect link works fine: https://docs.rs/crate/nix/0.31.2/target-redirect/x86_64-pc-windows-msvc/nix/kmod/index.html
  • This was mentioned in Redirect from missing target to search page for default target #1416 so a regression perhaps?

---

On this topic I also have a question/proposal: Would it make sense or be feasible, when the URL doesn't specify a target, to try locating the item in all targets, and redirect to the first target if the item was found?

Still using nix as an example: nix@0.31.2 has x86_64-unknown-linux-gnu as the default target, which doesn't have the item nix/sys/termios/fn.cfmakesane.html, but the target x86_64-unknown-freebsd does:

• Right now, https://docs.rs/nix/0.31.2/nix/sys/termios/fn.cfmakesane.html returns 404 (which I suppose should instead be the search page)
• I'm wondering if this would make more sense:
  • https://docs.rs/nix/0.31.2/x86_64-unknown-linux-gnu/nix/sys/termios/fn.cfmakesane.html goes to search, which is the current behavior (because the URL specifically asked for that platform);
  • https://docs.rs/nix/0.31.2/nix/sys/termios/fn.cfmakesane.html will redirect to https://docs.rs/nix/0.31.2/x86_64-unknown-freebsd/nix/sys/termios/fn.cfmakesane.html

So instead of interpreting a URL without a target as "the default target," perhaps interpret it as "target unspecified"?

[syphar]

So many questions :)

So, generally, our current design:

• every URL with a target (or without = default target) is treated like a request to a file server. You'll get a 404 when the file doesn't exist. I remember an issue where we discussed having a more user-friendly 404 page, perhaps including a search-link.
• "without target = default" is quite standard, and I don't think we should change that. Every crate can define what their default target is.
• when you switch between targets or versions ( = we don't know if the same page exists in the other target/version), we fallback to a search.

So, first of all, for your usecase: you could always generate URLs using the /target-redirect/ handlers. Also for the default target.

Then, second:
it seems like some of the 404 or 302 you mentioned don't match the design from above.

I would need to dig through them one by one, and match them, I'm happy to take a PR about this, and provide mentoring instructions.

[tonywu6]

From a reader's perspective, an improved 404 page would help! Especially if the /:crate/:version part is correct, then it would be useful for the 404 page to at least have the usual navbar at the top.

(I found #2568 which seems related to this)

a PR about this

Definitely interested! I will take a look soon