I've tested it with 7.1 and MacTCP and it doesn't work for a couple reasons, but at least one of them is interesting in why it doesn't work on 7.1 and does on 7.6.1.
When the File Manager on 7.1 does lookups, it does chained async reads. So when it traverses the filesystem, it does a read of one block, and from the completion routine of that read, it inspects the block and issues another read, and so on down the line until it finds what it is looking for. The HTTP Disk driver internally does chained MacTCP operations, so a read of the HTTP Disk issues an async TCPCreate, and from the completion routine of that, issues a TCPOpen, TCPSend, TCPRecv, TCPClose, TCPRelease, and when finally done, calls the original caller's completion routine. That chain gets huge, which means the stack gets huge, runs into the heap and boom hang.
The "solution" is to call the IO's completion routine from IO an interrupt, which is easily accomplished with the Deferred Task Manager. But the catch is, MacTCP processes received packets (indirectly) from the NIC's interrupt handler. The NIC interrupts when it gets a packet, interrupt handler eventually hands the data to MacTCP, etc. So, when the HTTP Disk returns an IO through an interrupt handler in this situation, the File Manager then issues another read operation, which then goes to MacTCP to open a new connection to the server. The TCP SYN goes out, but the SYN ACK is never processed because we're all from an interrupt handler, the TCP open times out, the IO fails, and bad news.
None of this is a problem on 7.6.1 because the File Manager does things differently and the stack never grows too large and there's no problem.
Anyway, knowing is half the battle, right? Now that I know what the problem is, I've got some ideas on what to do to fix it.
When the File Manager on 7.1 does lookups, it does chained async reads. So when it traverses the filesystem, it does a read of one block, and from the completion routine of that read, it inspects the block and issues another read, and so on down the line until it finds what it is looking for. The HTTP Disk driver internally does chained MacTCP operations, so a read of the HTTP Disk issues an async TCPCreate, and from the completion routine of that, issues a TCPOpen, TCPSend, TCPRecv, TCPClose, TCPRelease, and when finally done, calls the original caller's completion routine. That chain gets huge, which means the stack gets huge, runs into the heap and boom hang.
The "solution" is to call the IO's completion routine from IO an interrupt, which is easily accomplished with the Deferred Task Manager. But the catch is, MacTCP processes received packets (indirectly) from the NIC's interrupt handler. The NIC interrupts when it gets a packet, interrupt handler eventually hands the data to MacTCP, etc. So, when the HTTP Disk returns an IO through an interrupt handler in this situation, the File Manager then issues another read operation, which then goes to MacTCP to open a new connection to the server. The TCP SYN goes out, but the SYN ACK is never processed because we're all from an interrupt handler, the TCP open times out, the IO fails, and bad news.
None of this is a problem on 7.6.1 because the File Manager does things differently and the stack never grows too large and there's no problem.
Anyway, knowing is half the battle, right? Now that I know what the problem is, I've got some ideas on what to do to fix it.