From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) by mx.groups.io with SMTP id smtpd.web11.26898.1598556233181356614 for ; Thu, 27 Aug 2020 12:23:53 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@broadcom.com header.s=google header.b=Ndzh28nL; 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.218.50, mailfrom: vladimir.olovyannikov@broadcom.com) Received: by mail-ej1-f50.google.com with SMTP id j25so9179254ejk.9 for ; Thu, 27 Aug 2020 12:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to:cc; bh=tiIoMLvVN1pTUXE0ufbKtLQGgueEM+2xuYrGL+Kv01c=; b=Ndzh28nLcfDv5F6915YniL1SBw+Xh+1PCj5mjha6wC/2xZkmnZABeNz8yrx9dwL1EZ O7eNfUyvBro4DWddF2H1drtoKSqBHPlxU5t3xLp3fmiFxWqE6kH/kpJS/VZE5BZPje1o L16GIUajT7WwFyr6t+tDW+KcDRWWuI9eyuWeI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:cc; bh=tiIoMLvVN1pTUXE0ufbKtLQGgueEM+2xuYrGL+Kv01c=; b=gLMy61Jzls1lME7DOozM3ZgrwgrRgmT37NAnIwrl9OUPgj3pVwIEX426wvA9miGvSO vbT51orIb1aa5D4LqAomySOBrlp5dD9S0XxVKCJ/rKDP+G904FwtFQhA40/dSKU5nmk0 ++nrbASnrZvrjq4kRUJNDwJs2THHJZtdyZKx/m0pa4it0TnVvz2DuynTKeuxF8YYaB2q sqOR8Y7oanHWyXuA/v7X40FE0NIYXJTPsRIvNe54WgFSqyLACFL2zezZGoQZKGONbjdx /aalKDRG7vOLgIhBbUHrU55sd1iNc0hVIpOqL7szWNmuKwYj3/wM++R9TRgfrbAecoMx lwfg== X-Gm-Message-State: AOAM5316ioakQIotgSNe8S0GMZ0RwSaS1xK6U0B2mWE7HID8G1iGwUTf Fx6v91WGpjs7XbWqAUzuwl9VIwUpmcF9WV+kyrMpYw== X-Google-Smtp-Source: ABdhPJx++S0leyljowR/8Xc+XpJ/zdyg6I9Aep74cIxKblZLWsZEEhMzecu15d9tlow2qGhftYRBSIcg5NdMA39blgo= X-Received: by 2002:a17:906:1757:: with SMTP id d23mr21512141eje.126.1598556231371; Thu, 27 Aug 2020 12:23:51 -0700 (PDT) From: "Vladimir Olovyannikov" MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdZ8p4+5RUCGVK+8QQOKwDj6vnzDwQ== Date: Thu, 27 Aug 2020 12:23:48 -0700 Message-ID: Subject: Http redirection handling using HttpDxe driver To: "Rabeda, Maciej" Cc: devel@edk2.groups.io Content-Type: text/plain; charset="UTF-8" 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