PXE boot does use TFTP to transfer the image, while TFTP bases on UDP which has alot of disadvantages.
Modern GPXE does use HTTP or FTP to transfer the image which much more better speed.
To satisfy your demand, all you need is a working GPXE server and Grub4dos bootloader.
Diskless client will request IP by DHCP, then download the gpxe module, then download grub.exe and iso image.
Grub.exe will load the image by mapping it to (0xff) memory.
I have wrote a detail tutorial here : http://www.linuxbyexamples.net/2012/08/boot-iso-image-from-http-server.html
Hope it can help you.
Cheers.
(My initial answer was premature. As promised, I've rewritten it after having gotten everything working.)
First of all, I've found that in general iSCSI-boot-enabling software is half-baked, and the disparate systems involved interoperate very poorly. For this reason I recommend instead going with a hardware-based solution such as iSCSI HBAs if possible. With that said I'll relate my experiences here in case it helps anyone.
To summarize what I found (I'm assuming you've set up DHCP and TFTP for PXE and an iSCSI target and have gotten as far as chaining to gPXE or iPXE):
gPXE and iPXE never write multiple NICs into the iBFT (iSCSI Boot Firmware Table), and this can impact Windows Server. I have discussed this problem in detail in a separate question here.
In addition to the above design limitation, gPXE has an actual bug that likewise affects systems with multiple network ports. I'll explain below. In order to avoid this bug, I used the "UNDI only" build of gPXE. This prevents gPXE from accessing the NICs directly and makes it instead use an API provided by the NIC's PXE loader. This makes gPXE think there is only one network port (the one it was loaded on), and this evades the bug. I am not sure if this bug is present in newer iPXE versions.
I was initially confused about the keep-san option in gPXE/iPXE. The keep-san flag affects gPXE's behaviour only if the boot fails. Therefore, this option is needed only on the very first boot when the installation is started.
Windows Server (at least 2012 and probably others) apparently does not tolerate moving the iSCSI initiator that provides its system disk from one network port to another. If Windows is booted from an initiator on a different network port than the one to which it was installed, Windows will crash (BSOD and/or reboot) during boot, at the handoff to the MS initiator.
There is an acknowledged feature/issue in Windows Server (2003 and up) where it will use the gateway, if one is specified, to access the target, even if the target is on the local subnet. If the gateway is unavailable or doesn't route back onto the same port, the boot will fail at the handoff to the MS initiator. Make sure no gateway setting is given out by the DHCP if one isn't needed.
The gPXE bug I mention above involves the iBFT (iSCSI Boot Firmware Table). This is an object which is placed into memory by the pre-boot system which contains information about the NICs, iSCSI initiator, and the iSCSI target to use as the system disk. The OS uses this information to continue booting once it switches to protected mode. The format is specified here.
Suspecting a problem in the information gPXE was placing in the iBFT, I programmed a boot sector which dumps the contents of the iBFT to the screen. Using this I found that the data written by gPXE is under certain circumstances erroneous.
As mentioned, gPXE only writes one NIC record into the iBFT, but in some situations, the information written to that one NIC record is jumbled up. The MAC address and PCI address will correspond to one NIC, but the local IP and gateway addresses will correspond to another. This is most likely to happen if the SAN is not on the first NIC.
To add to the confusion, this incorrect iBFT information is written if gPXE boots automatically, but when booting from gPXE's command prompt, depending on the exact sequence of commands entered, the correct information may be written. Throw in the fact that Windows will manifest symptoms identical to those caused by this bug if its NIC has been changed (even given a correct iBFT), and you can see why I tore my hair out.
By the way, in my original question I had thought that it was working for Server 2008 R2 but not Server 2012. (I'm editing that out as it's misleading.) I suspect there's actually no difference in their underlying behaviour and that the different outcomes owed to the subtleties of the above problems and minor variations in my tests.
Best Answer
I believe you can do this by pxe booting memdisk as the kernel and specifying the iso file as the initrd.
http://syslinux.zytor.com/wiki/index.php/MEMDISK
I'm not entirely sure that you will be able to do this completely over http, you may need tftp support in that repo directory.
Further information:
http://www.etherboot.org/wiki/bootingmemdisk