Tianocore/edk2.git/NetworkPkg/HttpBootDxe, branch dependabot/github_actions/actions/setup-python-6

NetworkPkg: Add PCD to control http boot enable or disable.

2025-06-11T19:07:48+00:00

Add PCD to control http boot enable or disable. Signed-off-by: jie.fu

NetworkPkg/HttpBootDxe: Wait for IPv6 DAD before issuing DHCPv6 requests

2025-05-29T14:29:11+00:00

Align HTTP Boot behavior with PXE by inserting a delay to wait for IPv6 Duplicate Address Detection (DAD) to complete before issuing DHCPv6 requests. This avoids EFI_NO_MAPPING errors caused by early DHCP attempts before a valid IPv6 address is ready. Problem: On some platforms, HTTP boot over IPv6 fails with EFI_NO_MAPPING during initial DHCPv6 attempts. The failure is due to the system trying to send Solicit messages before IPv6 DAD finishes, resulting in no usable IP address at that time. Solution: Insert a retry mechanism to poll DAD completion when the initial call to Dhcp6->Start() fails with EFI_NO_MAPPING. This behavior mirrors PXE's handling, where it waits for a valid IPv6 address to be assigned before retrying the DHCPv6 flow. Signed-off-by: Sam Tsai [Wiwynn]

NetworkPkg/HttpBootDxe: Add proxy connect flow to *GetBootFile()

2025-03-13T00:34:01+00:00

- Add HTTP CONNECT flow to connect to Proxy Server - Provide Proxy URL to HTTP GET/HEAD Requests Implementation based on UEFI Specification v2.11 - Section 24.7.10 to use HTTP CONNECT method to connect to Proxy Server and use it to forward the HEAD/GET request to Endpoint Server's BootURI. - Section 29.6.6 to use EFI_HTTP_CONNECT_REQUEST_DATA structure for HttpMethodConnect usage in EFI_HTTP_PROTOCOL.Request() Signed-off-by: Saloni Kasbekar

NetworkPkg/HttpBootDxe: Add ProxyUri handling in start/stop path.

2025-03-13T00:34:01+00:00

Update HTTP Boot Start/Stop to handle ProxyUri Implementation based on UEFI Specification v2.11 section 24.7.10 to use HTTP CONNECT method to connect to Proxy Server and use it to forward the HEAD/GET request to Endpoint Server's BootURI. Signed-off-by: Saloni Kasbekar

Network/HttpBootDxe: Modify device path parser to detect Proxy URI node.

2025-03-13T00:34:01+00:00

Update device path parser to detect device path with Proxy URI Implementation based on UEFI Specification v2.11 Section 24.7.3.1 Signed-off-by: Saloni Kasbekar

NetworkPkg/HttpBootDxe: Added ProxyUri field to HTTP_BOOT_PRIVATE_DATA.

2025-03-13T00:34:01+00:00

Update HTTP_BOOT_PRIVATE_DATA structure to include ProxyUri Signed-off-by: Saloni Kasbekar

NetworkPkg/HttpBootDxe: Use ProxyUri from HII to build boot option

2025-03-13T00:34:01+00:00

Build boot option with HII provided ProxyUri by utilizing URI validation path in HII callback for ProxyUri. Implementation based on UEFI Specification v2.11 Section 24.7.3.1 to use device path with ProxyURI included Signed-off-by: Saloni Kasbekar

NetworkPkg/HttpBootDxe: Add Proxy URI field to HII.

2025-03-13T00:34:01+00:00

Add Proxy URI field to HTTP Boot HII Signed-off-by: Saloni Kasbekar

NetworkPkg/HttpBootDxe: Report download error when resume attempts fail

2024-10-15T22:26:37+00:00

When all resume attempts to continue an interrupted NBP file download have failed, report the failure status to the caller. Original implementation was returning success when number of retries reaches the limit defined by PcdMaxHttpResumeRetries. Signed-off-by: Leandro Gustavo Biss Becker

NetworkPkg/HttpBootDxe: Correctly uninstall HttpBootCallbackProtocol

2024-09-15T21:18:08+00:00

The existing HttpBootUninstallCallback was passing the wrong handle (the PrivateData root controller handle, not the correct child IPv4 or IPv6 NIC controller handle; cf HttpBootInstallCallback for matching logic) and was also passing the address of a pointer to the interface to be removed rather than the pointer itself, so always failed with EFI_NOT_FOUND. This resulted in the prior behaviour that if multiple HTTP boot attempts were made, on the second and subsequent attempts the instance of this protocol installed by the first attempt would be re-used. As long as only one driver using the protocol is installed, this ends up producing the same results as if the protocol had been uninstalled then reinstalled correctly. After this commit, the protocol is installed at the start of an HTTP boot attempt and uninstalled it at the end of it (assuming nothing else has accessed the protocol in a way which blocks the uninstall). It might seem attractive to add an ASSERT to confirm when debugging that the uninstall succeeds as expected, but this is recommended against because uninstallation of protocol interfaces is allowed to fail under the UEFI model: https://edk2.groups.io/g/devel/message/117469. An ASSERT could therefore arise from a sequence of events which is perfectly valid - or at least is out of the control of this driver. Signed-off-by: Mike Beaton