[tftp] Mangle initial slash on TFTP URIs
authorMichael Brown <mcb30@ipxe.org>
Thu, 21 Jan 2016 16:24:16 +0000 (16:24 +0000)
committerMichael Brown <mcb30@ipxe.org>
Thu, 21 Jan 2016 18:00:33 +0000 (18:00 +0000)
commitf0e9e55442023c2f18e62cf74fe9098e0a6f5347
treebb6ad3c5c63bbec368795b86d3e4f897a0421381
parent42c2a6aab7727e7359600515471f463c65315ff0
[tftp] Mangle initial slash on TFTP URIs

TFTP URIs are intrinsically problematic, since:

- TFTP servers may use either normal slashes or backslashes as a
  directory separator,

- TFTP servers allow filenames to be specified using relative paths
  (with no initial directory separator),

- TFTP filenames present in a DHCP filename field may use special
  characters such as "?" or "#" that prevent parsing as a generic URI.

As of commit 7667536 ("[uri] Refactor URI parsing and formatting"), we
have directly constructed TFTP URIs from DHCP next-server and filename
pairs, avoiding the generic URI parser.  This eliminated the problems
related to special characters, but indirectly made it impossible to
parse a "tftp://..." URI string into a TFTP URI with a non-absolute
path.

Re-introduce the convention of requiring an extra slash in a
"tftp://..." URI string in order to specify a TFTP URI with an initial
slash in the filename.  For example:

  tftp://192.168.0.1/boot/pxelinux.0  => RRQ "boot/pxelinux.0"
  tftp://192.168.0.1//boot/pxelinux.0 => RRQ "/boot/pxelinux.0"

This is ugly, but there seems to be no other sensible way to provide
the ability to specify all possible TFTP filenames.

A side-effect of this change is that format_uri() will no longer add a
spurious initial "/" when formatting a relative URI string.  This
improves the console output when fetching an image specified via a
relative URI.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
src/core/uri.c
src/net/udp/tftp.c
src/tests/uri_test.c