From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by mx.groups.io with SMTP id smtpd.web12.47413.1598634261421265574 for ; Fri, 28 Aug 2020 10:04:22 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@broadcom.com header.s=google header.b=UxylCVpl; spf=permerror, err=parse error for token &{10 18 %{i}._ip.%{h}._ehlo.%{d}._spf.vali.email}: invalid domain name (domain: broadcom.com, ip: 209.85.208.44, mailfrom: vladimir.olovyannikov@broadcom.com) Received: by mail-ed1-f44.google.com with SMTP id q21so1793082edv.1 for ; Fri, 28 Aug 2020 10:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=zDIgCmDLjVksdTzdEg0hKqr5fwQx8Z2L21p5cq0jD+Y=; b=UxylCVpl6Xj5VxsfvTLzlk2FLW4QPx3PmOxLCn9lzEGy41dXEFGufsliVd4+C4TEKK x7rpqCXwZKZoICraeaJ/DGEGQi/NYi3ioK0sbsobp35NnFjJATEJlw10Y46I+l3BTCDV i6ImlEdZMEu3/hKlJ0KJv0n7kbr7SQShqlVE4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=zDIgCmDLjVksdTzdEg0hKqr5fwQx8Z2L21p5cq0jD+Y=; b=hTSmpM3xs7dxP0perjDhOpiiC0ZXgs5OdbXKvQH6m0rwtPhbaBQCV6XS7SEwQLPNnN Jbam6RGH5STxlMN7ax9OnqxJjjUtNFHDDi0pPP0pLBYtBWeENW9AtYOSKEjZ3iVSHgOm XKhR8kzU7usQtINf/hfuyvFIPotSUIWEPlOwXuDK5CV6uul98jS6pUR/EcG73ntaX25u HaEJW+c4SO1R20O9snUua3V0rZSby80TRUNkr/A+ke8P2rY+2VgX5MQtAKxftFZCSaCY 7PmApk05pi9+FnNmVJul4ykFn6bXjfr0IH3ebBca13SZ0NzTM4W6IqSsym2n/n56lsOA bPsw== X-Gm-Message-State: AOAM532lz6Q5s9G5R7pLQ9mWvEQ77NpnpGnWF7kbSn6Sfn6mrp4qhWHS NXdmHP8dJizEUk4LkujsluYom30FLUlaHwtQC7qMoA== X-Google-Smtp-Source: ABdhPJyHiIXSqOw7h8ASVk6slxCwWX+HJm7RtiVMLgM8iURpHcWxvzYFV45+ADyEddntU4rZ9JIzz8M8cwRZ0SAm0jc= X-Received: by 2002:a50:ed8d:: with SMTP id h13mr2806925edr.50.1598634259760; Fri, 28 Aug 2020 10:04:19 -0700 (PDT) From: "Vladimir Olovyannikov" References: <98b72f0f-650f-22e7-ce13-1f528077e1cf@linux.intel.com> In-Reply-To: <98b72f0f-650f-22e7-ce13-1f528077e1cf@linux.intel.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIxmF8GwbAYWREP9tVQIDNfThXgGQLcWGkgqIClU4A= Date: Fri, 28 Aug 2020 10:04:17 -0700 Message-ID: <5afd3d4a6f3b7ebd282b80b77f402d85@mail.gmail.com> Subject: Re: Http redirection handling using HttpDxe driver To: "Rabeda, Maciej" Cc: devel@edk2.groups.io, Laszlo Ersek Content-Type: text/plain; charset="UTF-8" > -----Original Message----- > From: Rabeda, Maciej > Sent: Friday, August 28, 2020 8:27 AM > To: Vladimir Olovyannikov > Cc: devel@edk2.groups.io > Subject: Re: Http redirection handling using HttpDxe driver > > Hi Vladimir, > > I got your message, I will look into it next week. > Have a great weekend! > Thank you Maciej, I looked through the code and found that my redirection assumption was incorrect. Apparently, one must destroy the socket before resubmitting a request for a different server. I am going to submit patchset v8. Please review it when you have a chance. @Laszlo This does not affect a direct download when there is no redirection, which you tested. Have a great weekend! Thank you, Vladimir > Maciej > > On 27-Aug-20 21:23, Vladimir Olovyannikov wrote: > > Hi Maciej, > > > > I would like to get your input (and the HttpDxe driver guys) on the > > issue I see with Http redirection (using HttpDynamicCommand) > > Basically, let's say that we connect to a server "server.com" > > > > Request: > > GET / HTTP/1.1 > > Host: server.com > > > > Reply: > > HTTP/1.1 301 Moved permanently > > Location: www.server.com > > > > By RFC, the client reissues the request like following and connects to > > www.server.com: > > Request: > > GET / HTTP/1.1 > > Host: www.server.com > > > > Reply: > > HTTP/1.1 200 OK > > > > I have an issue of getting EFI_ACCESS_DENIED in SockInterface.c on the > > redirection. > > The logic is: > > 1. Send a request > > 2. Parse the response. If there is a redirection code returned, then > > a) cancel Http connection > > b) resubmit to the proper host with proper host header. > > > > Obviously, there are no issues with a). However, there is an issue > > with b) When the second request is being sent, EfiHttpRequest sets > > Configure and Reconfigure flags, closes and cancels Http connection > > with HttpCloseConnection/EfiHttpCancel. > > Everything is OK at this point. Note that the socket is closed, but > > it's ConfiguredState is 1, and is not changed. > > Now, HttpInitSession() is called with Configure flag. > > It calls into HttpConfigureTcp4(), which in turn calls > > Tcp4Configure(). > > Here everything is fine until > > SockConfigure is called. > > The SockConfigure checks if ConfigureState is "not configured" > > (see above, the ConfigureState is not changed on Http session > cancel/close). > > So, the SockConfigure returns EFI_ACCESS_DENIED error as the > > socket is configured, and this is returned to HttpConfigureTcp4(). > > Which, in turn, returns an error up, and the Http in > > HttpDynamicCommand gets this error, reports it and aborts the operation. > > > > If I change the line in HttpConfigureTcp4, line 1108 in HttpProto.c > > from if (EFI_ERROR (Status)) { > > DEBUG ((.....)); > > return Status; > > } > > to > > if (EFI_ERROR (Status) && (Status != EFI_ACCESS_DENIED)) { > > DEBUG ((...)); > > return Status; > > } > > then EFI_SUCCESS is returned, socket placeholder is reused, and > > multiple redirections works properly (I tried this scheme: > > server.com->www.server.com->www1.server.com->got content). > > I suspect, it is wrong to make an assumption that the ACCESS_DEINED > > returned from Tcp4Configure() would be because of the socket. > > Maybe, I am missing something? Can you help? > > > > Thank you, > > Vladimir