From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by mx.groups.io with SMTP id smtpd.web11.45502.1598628421812810313 for ; Fri, 28 Aug 2020 08:27:01 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=none, err=permanent DNS error (domain: linux.intel.com, ip: 134.134.136.31, mailfrom: maciej.rabeda@linux.intel.com) IronPort-SDR: Sc3Ty3vcuoFbSDLQYWJ5A2A2wQKmEXE2WvUqfUFC+Blnw+gQU4WD05mSP+FwUdYmSxWrB9fFrT PCKKggqvfJhg== X-IronPort-AV: E=McAfee;i="6000,8403,9727"; a="218235873" X-IronPort-AV: E=Sophos;i="5.76,364,1592895600"; d="scan'208";a="218235873" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Aug 2020 08:27:01 -0700 IronPort-SDR: 0vbK/0W7Rd5pbvz6CEbmLxYoMXaK+HE+kHvkNUk5lSxbwe+6rmVoWTQSaJhQUX2bpR2KB7BjtO YkFFoSXkEZUg== X-IronPort-AV: E=Sophos;i="5.76,364,1592895600"; d="scan'208";a="475719698" Received: from mrabeda-mobl.ger.corp.intel.com (HELO [10.249.142.173]) ([10.249.142.173]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Aug 2020 08:27:00 -0700 Subject: Re: Http redirection handling using HttpDxe driver To: Vladimir Olovyannikov Cc: devel@edk2.groups.io References: From: "Maciej Rabeda" Message-ID: <98b72f0f-650f-22e7-ce13-1f528077e1cf@linux.intel.com> Date: Fri, 28 Aug 2020 17:26:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: pl Hi Vladimir, I got your message, I will look into it next week. Have a great weekend! 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