From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (NAM04-BN8-obe.outbound.protection.outlook.com [40.92.47.85]) by mx.groups.io with SMTP id smtpd.web12.5003.1598672389547858520 for ; Fri, 28 Aug 2020 20:39:50 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@outlook.com header.s=selector1 header.b=NDrfav/C; spf=pass (domain: outlook.com, ip: 40.92.47.85, mailfrom: spbrogan@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=k2PASiIMRcL7kt0GGNx92UJoc4/dgYuQU0RiqMZKLbf90OWD61NftbOV6zHcTMz3GtS9CXeLTe9Hx7j54pyqGh+xaxkHrV3LxIOzAd4iyoz08n2wp4TG1EojVDxljxzo4eLUELxOPRo9sBv1enMaYrknZmJYN0SJTpx+vPTuT3ffxIcyZ1eIhZYm3WVZk1untCDCBXQ3TQ7aSeM0fZddmP+tuzxn0VtjgF/xK4CHeVuobWQCR1XFBbPq6O7v9weQ6v6F6ZCl7A+ff5/fcDy5N+Fy//oZkdGMEIN4jUxpfozbXxvYqkwemn0AtpAfAibacDQK24SwrGFINEa7J9LIYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SsxCoa3GmOKn8EeaCvai5PSSdNXuWu/rlZlxZdfnhwE=; b=dFgQPCWYdz95gkccdax8NUa6JGFEcladyS7Xpw+ASiQLwDy/IZiTDp5iKa5Ki1y3UxAGiao3Ic8NKoyl9RJ4q5ueLGsiCzLsU87Phld6GO4WUGSHu/K4f6X2/Qwhuk4r4/nL6KffBgiou/g7Z8AmEe5tbIPKHBFBBpNBH6FGFx0Khi73j7bn07OYeYZh+XMv1E5m0Yp49a0v+tdcg0xZ6SgsvBzJv5KQqFkytSYsABz+wVlfTJKADWjRPiJAzX6yyBdd9+CHv4ItiAjGXUtzV+p/BhnLyenGoY5RqdkRYnY7Vnw3fNDkkVutQwf6OTTqqFbI7C49sgLIDbfLs/Kq9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SsxCoa3GmOKn8EeaCvai5PSSdNXuWu/rlZlxZdfnhwE=; b=NDrfav/CipPiaX29UNUnlrlDFog+BNnU5lc1E7cmTR0OOwa0avQ3n568Su4POpEzkISW1c0JqS/yIui5O7TzZmg4Bv1oFoTvSL/ACtHT8TJtZFPv0EmQpLB54aTWUPS1Xuz9dnLsJ9Zyu4xv0ZZlOPtmNe0qhK1G/ITqQc50OT/iTiQ44cqQJg7RMQb5SSS/CNOTJIij8gFLRFojlKlOZ6VsJTx7TUzt2L7iFAZ4TJkbi7ustVEW2rDgOq0W+0N5P+Nc2a5eTw6ctRIS1x3PB+NUZiFV2F2o0krsxMV2Hg84bKAJYlJhMa91jhf05xyxq2f9UjLQSUTRpGR87Hgc3Q== Received: from DM6NAM04FT054.eop-NAM04.prod.protection.outlook.com (2a01:111:e400:7ea3::41) by DM6NAM04HT150.eop-NAM04.prod.protection.outlook.com (2a01:111:e400:7ea3::474) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.21; Sat, 29 Aug 2020 03:39:47 +0000 Received: from BN8PR07MB6962.namprd07.prod.outlook.com (2a01:111:e400:7ea3::4b) by DM6NAM04FT054.mail.protection.outlook.com (2a01:111:e400:7ea3::318) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.19 via Frontend Transport; Sat, 29 Aug 2020 03:39:47 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:241C3B3667EAB3F4CD6AF371763F3974C5E4F9976F07BE9CEC91894D583E52C9;UpperCasedChecksum:E6A46CC65E69C7E2DBFCA500AADB485379C7F22A46E799FD076455EA11C62E8F;SizeAsReceived:8937;Count:49 Received: from BN8PR07MB6962.namprd07.prod.outlook.com ([fe80::b1be:f3e4:f6e:66c3]) by BN8PR07MB6962.namprd07.prod.outlook.com ([fe80::b1be:f3e4:f6e:66c3%5]) with mapi id 15.20.3326.023; Sat, 29 Aug 2020 03:39:47 +0000 Subject: Re: [edk2-devel] Http redirection handling using HttpDxe driver To: devel@edk2.groups.io, vladimir.olovyannikov@broadcom.com, "Rabeda, Maciej" Cc: Laszlo Ersek References: <98b72f0f-650f-22e7-ce13-1f528077e1cf@linux.intel.com> <5afd3d4a6f3b7ebd282b80b77f402d85@mail.gmail.com> From: "Sean" Message-ID: Date: Fri, 28 Aug 2020 20:39:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 In-Reply-To: <5afd3d4a6f3b7ebd282b80b77f402d85@mail.gmail.com> X-ClientProxiedBy: MWHPR19CA0011.namprd19.prod.outlook.com (2603:10b6:300:d4::21) To BN8PR07MB6962.namprd07.prod.outlook.com (2603:10b6:408:d6::11) Return-Path: spbrogan@outlook.com X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from 255.255.255.255 (255.255.255.255) by MWHPR19CA0011.namprd19.prod.outlook.com (2603:10b6:300:d4::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.19 via Frontend Transport; Sat, 29 Aug 2020 03:39:46 +0000 X-Microsoft-Original-Message-ID: X-TMN: [POQgTvmFBn9AQifXd0RGZKvL5s6La/SL] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 49 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 96ebbf1c-499b-4139-3cb0-08d84bcd2d01 X-MS-TrafficTypeDiagnostic: DM6NAM04HT150: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: iDb1VyGzlKHvqNv9iSoPnjiZzcLsXJDdy1DJxePJufW7E5fgBz+DOoi87qYIksyXR7zg4xvmeGnSmCQfnJdRcvvhQapMdQ3wy4q6bGPjdMafrHSlh04jShW/EpaSV6LZN3bs31GWr4k2wpMhMSq6HolMb0F8HbiFdncE6Mx7R8ZSgC/vXFwhodxYicUIU1wE3cWcEkgGrmt8d1yAHkdvVc6yeqRDQJLpe81wP+UdsTjpTKmsBlwyB5iB5ADQZJ6S X-MS-Exchange-AntiSpam-MessageData: b6boh9DEeYMfXUjvYM+pm+DNfOV8PjBpe5Aku65VduEWhNTW6B/wN7bnbKhBSZIbyg0psg5Dto7wo71GjugcB2LZUpywhuWcJE8l0L/wqJ1Qu9EAq+tcA8lgpGXIo0/QJtksD4rBuifg4y74XVFXfw== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 96ebbf1c-499b-4139-3cb0-08d84bcd2d01 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Aug 2020 03:39:47.3178 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: DM6NAM04FT054.eop-NAM04.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM04HT150 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit I think this is the similar to issue 1674 which was reported in early 2019. https://bugzilla.tianocore.org/show_bug.cgi?id=1674 I'll check internally to find out what we ended up doing to work around it. I think we closed the socket and opened a new one. This was less than ideal and is not intuitive given the API. Thanks Sean On 8/28/2020 10:04 AM, Vladimir Olovyannikov via groups.io wrote: >> -----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 > > >