github/JavaScriptServices
1
1
Fork 0
mirror of https://github.com/aspnet/JavaScriptServices.git synced 2025-12-22 17:47:53 +00:00
Code Issues Packages Projects Releases Wiki Activity

In SpaProxy, don't fail if there are non-forwardable headers. Fixes #1543.

Browse Source
This commit is contained in:
Steve Sanderson
2018-02-21 14:02:19 +00:00
parent bf1121f402
commit 4b54cd1a32
1 changed files with 15 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
src/Microsoft.AspNetCore.SpaServices.Extensions/Proxying/SpaProxy.cs
View File

@@ -22,9 +22,9 @@ namespace Microsoft.AspNetCore.SpaServices.Extensions.Proxy
private const int DefaultWebSocketBufferSize = 4096;
private const int StreamCopyBufferSize = 81920;
// Don't forward User-Agent because of https://github.com/aspnet/JavaScriptServices/issues/1469
// Don't forward User-Agent/Accept because of https://github.com/aspnet/JavaScriptServices/issues/1469
// Others just aren't applicable in proxy scenarios
private static readonly string[] NotForwardedWebSocketHeaders = new[] { "Connection", "Host", "User-Agent", "Upgrade", "Sec-WebSocket-Key", "Sec-WebSocket-Version" };
private static readonly string[] NotForwardedWebSocketHeaders = new[] { "Accept", "Connection", "Host", "User-Agent", "Upgrade", "Sec-WebSocket-Key", "Sec-WebSocket-Version" };
public static HttpClient CreateHttpClientForProxy(TimeSpan requestTimeout)
{
@@ -205,9 +205,21 @@ namespace Microsoft.AspNetCore.SpaServices.Extensions.Proxy
foreach (var headerEntry in context.Request.Headers)
{
if (!NotForwardedWebSocketHeaders.Contains(headerEntry.Key, StringComparer.OrdinalIgnoreCase))
{
try
{
client.Options.SetRequestHeader(headerEntry.Key, headerEntry.Value);
}
catch (ArgumentException)
{
// On net461, certain header names are reserved and can't be set.
// We filter out the known ones via the test above, but there could
// be others arbitrarily set by the client. It's not helpful to
// consider it an error, so just skip non-forwardable headers.
// The perf implications of handling this via a catch aren't an
// issue since this is a dev-time only feature.
}
}
}
try