So far the base address of the Ethernet chip was a general property of all Ethernet drivers. It served two purposes:
1. Allowing to use a single Ethernet driver for a certain Ethernet chip, no matter what machine was connected to the chip.
2. Allowing use an Ethernet card in all Apple II slots.
However, we now use customized Ethernet drivers for the individual machines so 1.) isn't relevant anymore. In fact one wants to omit the overhead of a runtime-adjustable base address where it isn't needed.
So only the Apple II slots are left. But this should rather be a driver-internal approach then. We should just hand the driver the slot number the user wants to use and have the driver do its thing.
Independently from the aspect if the driver parameter is a base address or a slot number the parameter handling was changed too. For asm programs there was so far a specific init function to be called prior to the main init function if it was desired to chnage the parameter default. This was done to keep the main init function backward compatible. But now that the parameter (now the slot number) is only used on the Apple II anyhow it seems reasonable to drop the specific init function again and just provide the parameter to the main init function. All C64-only user code can stay as-is. Only Apple II user code needs to by adjusted. Please note that this change only affects asm programs, C programs always used a single init function with the Apple II slot number as parameter.
Beside the code for the actual feature this change introduces analysis of the URL to extract a potential filename to be used for saving. Doing so was a prerequisite for disk download because the filename extension in the URL is the only hint for distinguishing ProDOS sector order disk images from DOS 3.3 sector order images.
So far only the URL input was potentially repeated. Now the file input is potentially repeated as well. For normal file paths there's deliberately still no check. But when entering a drive specifier ("!Sx,Dx") then it is checked for plausibility - and there's an additional confirmation question to keep the user from overwriting the "wrong" disk.
With now having both the URL and file input potentially repeated it became clear that loading and saving the input history shouldn't be repeated - and if the user quits without having entered a valid input the history deliberately isn't saved at all.
So far we were reading (much) more bytes from the W5100 than necessary when processing the HTTP header. The byte were memmove'd to the beginning of the buffer.
However, when downloading a DOS 3.3 sector order disk image (*.dsk / *.do) then we need to place every DOS 3.3 sector at a certain point in the buffer to avoid additional memcpy's later. Therefore the HTTP header processing mustn't read (or rather commit) any body bytes from the W5100. So we now just check for the "\r\n\r\n" after each and every byte. This is of course less than optimal but small/simple - and the header isn't supposed to be that large anyway.
IP65 doesn't support TCP flow control. Therefore it doesn't make sense to write a program receiving a significant amount of data via TCP using IP65. From that perspective it makes sense that IP65's HTTP client doesn't allow to handle incoming data with a callback but requires a buffer being able to hold the whole HTTP body.
However, on the Apple II there's the Uthernet II card with its W5100 Ethernet controller chip. That chip has it's own TCP implementation supporting TCP flow control. Therefore the wget65 program uses the W5100 TCP capabilities for the HTTP client.
But even with the W5100 TCP implementation in place IP65 still plays a role for the wget65 program as it desires DHCP and requires (usually) DNS. Both are not supported by the W5100 capabilities.
