davidfowl
commented
5 years ago cc @jkotalik
Closed sln162 closed 5 years ago
davidfowl
commented
5 years ago cc @jkotalik
Tratcher
commented
5 years ago This class of issue is very difficult to debug without a trace of the user input that triggered it.
jkotalik
commented
5 years ago We made a change to the underlying form reader in preview4, which could have introduced unintended breaking changes. As a work around, @jmk92 can you increase the FormKey size limit to a larger value via the FormOptions: https://github.com/aspnet/AspNetCore/blob/master/src/Http/Http/src/Features/FormOptions.cs#L47.
@davidfowl @Tratcher After rereading the code, I think I may see the underlying difference. The original form reader verified the length of the form key based on the string length rather than the byte length. See https://github.com/aspnet/AspNetCore/blob/master/src/Http/WebUtilities/src/FormReader.cs#L221 vs https://github.com/aspnet/AspNetCore/commit/fc9e48877c75562af1d3879a57694f55d5685397#diff-f44d0d010602be96c8821603bcd529ccR154. In my opinion, checking the form key size in bytes is the right behavior, but it does create a behavioral breaking change from the previous form reader. Thoughts?
sln162
commented
5 years ago @jkotalik @Tratcher I've set up FormKey manually, which seems to solve the problem, but the request was initiated by my C # program (user use). The form sent is fixed. The length of the key can't exceed 2048, so it's strange.
T0 = Base64 of the picture
T1=md5
T2=md5
T3 = sha256
T4 = string
T5 = string
That's the rule. Value passes through UrlEncode, and the key with the name t0 exceeds 2048?
I think there may be hidden bugs. Post data is not well documented online, so it is not easy to reproduce.
Tratcher
commented
5 years ago 2048 is a hard limit to hit in chars or bytes, I suspect the encoded length difference is not the explanation here.
@jmk92 are "T0" your real key names? If not, can you give an example of your longest?
sln162
commented
5 years ago @Tratcher
Yes, "T0" is one of the real keys. The keys above are fixed.
This may be wrong once in thousands of requests, but the source of the request is initiated by the program, the program will not make mistakes, written "T0" can not become other.
I wondered if key and value were confused because of the lack of URL encoding, but the code found that URL encoding had been added before, which would not happen. I even suspect that some people intentionally sabotage, but the log tracking, is not man-made reasons. I could only guess that there might be hidden BUG in the process, leading to false trigger restrictions.
It's worth noting that three interfaces have such accidental errors. They all have the same characteristics. They all have a long Base64 value, but they are value. They should not trigger the restriction of key.
Tratcher
commented
5 years ago A client encoding bug seems possible, but you wouldn't only hit that on 3.0. More likely we have a parsing boundary condition we need to debug.
sln162
commented
5 years ago @Tratcher Sorry, my description is a bit absolute. The program may make mistakes, but this small part of the code is unlikely to make mistakes. The string is written, the key is prescribed, he either fails to send the problem, once sent out, T0 is T0, Vaule I also used the URL encoding. As you said, it is impossible that 2.2 will be all right. After 3.0, errors will happen every day.
I think the problem is still with the Value of the super-long Base64 string, which might accidentally fit as a key? Of course, that's just my guess.
davidfowl
commented
5 years ago If you can provide us with some data then we can verify what the issue is.
analogrelay
commented
5 years ago @jmk92 to help us diagnose this issue, would you be able to capture a specific form data value that causes this error?
Base64 encoding does ring an alarm bell for me. In general, Base64 values are not URL-safe (they contain + and = characters). I realize this isn't a URL value, but a lot of the parsing is similar.
jkotalik
commented
5 years ago @jmk92 I tried to repro this with the input you provided, and I see it parsing correctly. I assume the data the client sends is different every time. If you could find an input that causes the exception, that would significantly speed up the investigation.
analogrelay
commented
5 years ago For now we'll add a quirks mode switch to go back to the old pre-3.0 parser until we can investigate further.
jkotalik
commented
5 years ago @anurse this is the only issue I'd be concerned about on my plate for preview8. We may need to fuzz the new formpipereader. I can make a quick PR to add a quirk mode to revert to the old one, but we should try to find the issue soon as this would be patch worthy.
analogrelay
commented
5 years ago I can make a quick PR to add a quirk mode to revert to the old one
Let's do this for 3.0 and investigate further post-3.0.
Tratcher
commented
5 years ago I reviewed the example data and the encoding is not up to spec.
That said, I don't see how these encoding issues would trigger the above issue, & is not in the Base64 character set, and = would always be encoded as %3D in values.
sln162
commented
5 years ago @jkotalik I tried to log content, but failed. I tried to set up a layer of nginx to record detailed logs, which should be captured.
@Tratcher Last time the content was one interface, this time another interface, please see if there is any difference.
Tratcher
commented
5 years ago That one doesn't have the newline issue (no %0A's), but it's still doing Base64 and UrlEncode as separate encoding steps. Properly encoded you would have no %2f, %2b, or %3d
This sample did have some interesting unicode at the end. &Remark=用户请求. @jkotalik maybe there is a character encoding component to this.
sln162
commented
5 years ago @Tratcher The value of the last parameter is Chinese, and I did not unicode it.
Tratcher
commented
5 years ago @jmk92 it was likely transmitted in utf-8 byte encoding, and the parser may not be interpreting utf-8 characters correctly.
sln162
commented
5 years ago I found it, logged 2048 errors, and nginx recorded Post's data.
davidfowl
commented
5 years ago @jmk92 Which key ends up being reported as too long?
davidfowl
commented
5 years ago I can reproduce the issue.
sln162
commented
5 years ago @davidfowl
This is another error in Post data. I try to submit it it with simulation tools. Every time it is http500, but after removing the last parameter in Chinese, 200 is OK. Maybe it's because of Chinese encoding that this happens by chance.
davidfowl
commented
5 years ago I found the issue and have a fix for it. @anurse, can we squeeze this into preview7?
analogrelay
commented
5 years ago Preview 7 is locked down pretty tight in preparation for release, so we can't make it happen there. @davidfowl suspects there's a workaround available by increasing the key/value limits in the form reader
We'll definitely get this fix in for Preview 8, and can re-evaluate if the workaround doesn't work.
davidfowl
commented
5 years ago using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Http.Features;
using Microsoft.AspNetCore.WebUtilities;
using Microsoft.Extensions.Options;
using Microsoft.Net.Http.Headers;
namespace WebApplication306
{
/// <summary>
/// Workaround for parsing issue https://github.com/aspnet/AspNetCore/issues/11262
/// </summary>
public class FormWorkaroundMiddleware
{
private readonly RequestDelegate _next;
private readonly FormOptions _formOptions;
public FormWorkaroundMiddleware(RequestDelegate next, IOptions<FormOptions> options)
{
_next = next;
_formOptions = options.Value;
}
public async Task Invoke(HttpContext httpContext)
{
if (httpContext.Request.HasFormContentType)
{
var previousFormFeature = httpContext.Features.Get<IFormFeature>();
httpContext.Features.Set<IFormFeature>(new WorkaroundFormFeature(httpContext.Request, previousFormFeature, _formOptions));
}
await _next(httpContext);
}
private class WorkaroundFormFeature : IFormFeature
{
private readonly HttpRequest _request;
private readonly IFormFeature _feature;
private readonly FormOptions _options;
public WorkaroundFormFeature(HttpRequest request, IFormFeature feature, FormOptions options)
{
_request = request;
_feature = feature;
_options = options;
}
private MediaTypeHeaderValue ContentType
{
get
{
MediaTypeHeaderValue.TryParse(_request.ContentType, out MediaTypeHeaderValue mt);
return mt;
}
}
private bool HasApplicationFormContentType =>
ContentType?.MediaType.Equals("application/x-www-form-urlencoded", StringComparison.OrdinalIgnoreCase) == true;
public bool HasFormContentType => _feature.HasFormContentType;
public IFormCollection Form { get => _feature.Form; set => _feature.Form = value; }
public IFormCollection ReadForm()
{
if (Form != null)
{
return Form;
}
if (HasApplicationFormContentType)
{
var encoding = FilterEncoding(ContentType.Encoding);
var formReader = new FormReader(_request.Body, encoding)
{
ValueCountLimit = _options.ValueCountLimit,
KeyLengthLimit = _options.KeyLengthLimit,
ValueLengthLimit = _options.ValueLengthLimit,
};
return Form = new FormCollection(formReader.ReadForm());
}
return _feature.ReadForm();
}
public async Task<IFormCollection> ReadFormAsync(CancellationToken cancellationToken)
{
if (Form != null)
{
return Form;
}
if (HasApplicationFormContentType)
{
var encoding = FilterEncoding(ContentType.Encoding);
var formReader = new FormReader(_request.Body, encoding)
{
ValueCountLimit = _options.ValueCountLimit,
KeyLengthLimit = _options.KeyLengthLimit,
ValueLengthLimit = _options.ValueLengthLimit,
};
return Form = new FormCollection(await formReader.ReadFormAsync());
}
return await _feature.ReadFormAsync(cancellationToken);
}
private Encoding FilterEncoding(Encoding encoding)
{
// UTF-7 is insecure and should not be honored. UTF-8 will succeed for most cases.
if (encoding == null || Encoding.UTF7.Equals(encoding))
{
return Encoding.UTF8;
}
return encoding;
}
}
}
// Extension method used to add the middleware to the HTTP request pipeline.
public static class FormWorkaroundMiddlewareExtensions
{
public static IApplicationBuilder UseFormWorkaroundMiddleware(this IApplicationBuilder builder)
{
return builder.UseMiddleware<FormWorkaroundMiddleware>();
}
}
}@davidfowl
After I tried to add middleware, I encountered the error of public bool HasFormContentType => _feature. HasFormContentType; in the middle, _feature is NULL, that is, previousFormFeature is NULL. Comparing the code, is the example in the environment of 2.2? Is 3.0 no longer used for IHosting Environment? UseMvc has also been replaced. And 2.2 should not have this problem.
In 3.0, how should I modify it?
davidfowl
commented
5 years ago Ah sorry it turns out I wrote it in a 2.2 application and the above code had a bug. It should be fixed now.
sln162
commented
5 years ago The test is OK. Thank you.
davidfowl
commented
5 years ago @jmk I’d also like you to test out the fix once it’s available in a ci build. I’ll let you know when that is
sln162
commented
5 years ago @davidfowl
There seems to be a problem. If you use entity classes to receive parameters, there seems to be no problem.
But if you receive parameters with an entity class, Request.Form.Count is always 0, and then you start to check. If you don't use an entity class to receive, use Request.Form [] to return Form = new Form Collection (formReader. ReadForm ());an error has occurred: Synchronous operations are disallowed. Call ReadAsync or set Allo WSynchronousIO to true instead.
How to test CI build? Do I need to install the Ci build version? I can cooperate with the test.
davidfowl
commented
5 years ago There seems to be a problem. If you use entity classes to receive parameters, there seems to be no problem. But if you receive parameters with an entity class, Request.Form.Count is always 0, and then you start to check. If you don't use an entity class to receive, use Request.Form [] to return Form = new Form Collection (formReader. ReadForm ());
Can you paste the problematic code here? I'd like to fix it regardless.
How to test CI build? Do I need to install the Ci build version? I can cooperate with the test.
You can install a new SDK from here, it's the master column and it's preview8, it should contain the fixes for this issue.
sln162
commented
5 years ago The code is very simple, that is to register the middleware above. In any controller, you only need to call Request.Form ["parameters"], then submit it with simulation tools, and then report the above error, which is in the middleware.
If you use an entity class to receive parameters and call Request.Form.Count, the result is always 0
sln162
commented
5 years ago preview 8 CI SDK,There are no problems with the current tests.
davidfowl
commented
5 years ago I've updated the code above with the fix (I want to make sure it works when people start running into this). The cached form was being overwritten.
sln162
commented
5 years ago @davidfowl We used Preview 8 and encountered the following error.
2019-08-14 15:49:15.7426|1|ERROR|Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware|An unhandled exception has occurred while executing the request. Microsoft.AspNetCore.Connections.ConnectionResetException: The client has disconnected
---> System.Runtime.InteropServices.COMException (0x80070040): 指定的网络名不再可用。 (0x80070040)
--- End of inner exception stack trace ---
at Microsoft.AspNetCore.Server.IIS.Core.IO.AsyncIOOperation.GetResult(Int16 token)
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadBody()
at System.IO.Pipelines.PipeCompletion.ThrowLatchedException()
at System.IO.Pipelines.Pipe.GetReadResult(ReadResult& result)
at System.IO.Pipelines.Pipe.GetReadAsyncResult()
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadAsync(Memory`1 memory, CancellationToken cancellationToken)
at Microsoft.AspNetCore.Server.IIS.Core.HttpRequestStream.ReadAsyncInternal(Memory`1 buffer, CancellationToken cancellationToken)
at System.IO.Pipelines.StreamPipeReader.ReadAsync(CancellationToken cancellationToken)
at Microsoft.AspNetCore.WebUtilities.FormPipeReader.ReadFormAsync(CancellationToken cancellationToken)
at Microsoft.AspNetCore.Http.Features.FormFeature.InnerReadFormAsync(CancellationToken cancellationToken)
at Microsoft.AspNetCore.Mvc.ModelBinding.FormValueProviderFactory.AddValueProviderAsync(ValueProviderFactoryContext context)
at Microsoft.AspNetCore.Mvc.ModelBinding.CompositeValueProvider.CreateAsync(ActionContext actionContext, IList`1 factories)
at Microsoft.AspNetCore.Mvc.ModelBinding.CompositeValueProvider.CreateAsync(ControllerContext controllerContext)
at Microsoft.AspNetCore.Mvc.Controllers.ControllerBinderDelegateProvider.<>c__DisplayClass0_0.<<CreateBinderDelegate>g__Bind|0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeInnerFilterAsync>g__Awaited|13_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextResourceFilter>g__Awaited|24_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|19_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
at Microsoft.AspNetCore.Diagnostics.StatusCodePagesMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware.SetRoutingAndContinue(HttpContext httpContext)
at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)
2019-08-14 15:49:15.7426|1|ERROR|Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware|An unhandled exception has occurred while executing the request. Microsoft.AspNetCore.Connections.ConnectionResetException: The client has disconnected
---> System.Runtime.InteropServices.COMException (0x80070040): 指定的网络名不再可用。 (0x80070040)
--- End of inner exception stack trace ---
at Microsoft.AspNetCore.Server.IIS.Core.IO.AsyncIOOperation.GetResult(Int16 token)
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadBody()
at System.IO.Pipelines.PipeCompletion.ThrowLatchedException()
at System.IO.Pipelines.Pipe.GetReadResult(ReadResult& result)
at System.IO.Pipelines.Pipe.GetReadAsyncResult()
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadAsync(Memory`1 memory, CancellationToken cancellationToken)
at Microsoft.AspNetCore.Server.IIS.Core.HttpRequestStream.ReadAsyncInternal(Memory`1 buffer, CancellationToken cancellationToken)
at System.IO.Pipelines.StreamPipeReader.ReadAsync(CancellationToken cancellationToken)
at Microsoft.AspNetCore.WebUtilities.FormPipeReader.ReadFormAsync(CancellationToken cancellationToken)
at Microsoft.AspNetCore.Http.Features.FormFeature.InnerReadFormAsync(CancellationToken cancellationToken)
at Microsoft.AspNetCore.Mvc.ModelBinding.FormValueProviderFactory.AddValueProviderAsync(ValueProviderFactoryContext context)
at Microsoft.AspNetCore.Mvc.ModelBinding.CompositeValueProvider.CreateAsync(ActionContext actionContext, IList`1 factories)
at Microsoft.AspNetCore.Mvc.ModelBinding.CompositeValueProvider.CreateAsync(ControllerContext controllerContext)
at Microsoft.AspNetCore.Mvc.Controllers.ControllerBinderDelegateProvider.<>c__DisplayClass0_0.<<CreateBinderDelegate>g__Bind|0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeInnerFilterAsync>g__Awaited|13_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextResourceFilter>g__Awaited|24_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|19_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
at Microsoft.AspNetCore.Diagnostics.StatusCodePagesMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware.SetRoutingAndContinue(HttpContext httpContext)
at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)
Repeated several times, I guess it should be related to this problem.
davidfowl
commented
5 years ago Looks completely unrelated. Can you file a separate issue? The exception says the client disconnected so it’s not the same form parsing bug
sln162
commented
5 years ago 2019-08-13 09:23:53.3897|1|ERROR|Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware|An unhandled exception has occurred while executing the request. Microsoft.AspNetCore.Connections.ConnectionResetException: The client has disconnected
---> System.Runtime.InteropServices.COMException (0x80070040): 指定的网络名不再可用。 (0x80070040)
--- End of inner exception stack trace ---
at Microsoft.AspNetCore.Server.IIS.Core.IO.AsyncIOOperation.GetResult(Int16 token)
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadBody()
at System.IO.Pipelines.PipeCompletion.ThrowLatchedException()
at System.IO.Pipelines.Pipe.GetReadResult(ReadResult& result)
at System.IO.Pipelines.Pipe.GetReadAsyncResult()
at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContext.ReadAsync(Memory`1 memory, CancellationToken cancellationToken)
at Microsoft.AspNetCore.Server.IIS.Core.HttpRequestStream.ReadAsyncInternal(Memory`1 buffer, CancellationToken cancellationToken)
at System.IO.StreamReader.ReadBufferAsync()
at System.IO.StreamReader.ReadAsyncInternal(Memory`1 buffer, CancellationToken cancellationToken)
at Microsoft.AspNetCore.WebUtilities.FormReader.BufferAsync(CancellationToken cancellationToken)
at Microsoft.AspNetCore.WebUtilities.FormReader.ReadNextPairAsyncImpl(CancellationToken cancellationToken)
at Microsoft.AspNetCore.WebUtilities.FormReader.ReadFormAsync(CancellationToken cancellationToken)
at Bypass_Web.FormWorkaroundMiddleware.WorkaroundFormFeature.ReadFormAsync(CancellationToken cancellationToken) in D:\.......\FormWorkaroundMiddleware.cs:line 112
at Microsoft.AspNetCore.Mvc.ModelBinding.FormValueProviderFactory.AddValueProviderAsync(ValueProviderFactoryContext context)
at Microsoft.AspNetCore.Mvc.ModelBinding.CompositeValueProvider.CreateAsync(ActionContext actionContext, IList`1 factories)
at Microsoft.AspNetCore.Mvc.ModelBinding.CompositeValueProvider.CreateAsync(ControllerContext controllerContext)
at Microsoft.AspNetCore.Mvc.Controllers.ControllerBinderDelegateProvider.<>c__DisplayClass0_0.<<CreateBinderDelegate>g__Bind|0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeInnerFilterAsync>g__Awaited|13_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextResourceFilter>g__Awaited|24_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|19_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Diagnostics.StatusCodePagesMiddleware.Invoke(HttpContext context)
at Bypass_Web.FormWorkaroundMiddleware.Invoke(HttpContext httpContext) in D:\.......\FormWorkaroundMiddleware.cs:line 40
at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)@davidfowl However, when using Preview 7, the location of the error occurred in FormWorkaround Middleware.
Refer to the error information above.
davidfowl
commented
5 years ago That’s because the exception happens when reading the body. File a new issue
tobiasbunyan
commented
5 years ago Just a preliminary heads up. I experienced this issue today (exact same exception in the same place, with the exception that it occurs in the "Fast" method) when running preview 9 on Azure Web App. Forcing our build back to preview 8 fixed the problem. The posted form data was incredibly small but I haven't had a chance to test it exclusively with the preview 9 "Fast" method code yet.
Tratcher
commented
5 years ago @tobiasbunyan see https://github.com/aspnet/AspNetCore/issues/13719 and lower your value length limit.
After switching to preview 5、6, you often encounter the following error logs
Tracking access logs found that the parameters of the web API requested by the client were normal and did not exceed the limit. Strangely, from 2.2, the code of the interface did not change, just upgraded to preview 5, and from that day on, there were constant error logs, sometimes several minutes, sometimes dozens of minutes, I am sure. Not when the user requests that the limit is exceeded.
The accepted parameter is an entity class, which is received through the [FromForm] form and works well, but requests are rejected from time to time.
I'm looking forward to Preview 6 solving this problem. The result is the same. It's been going on for more than ten days. It's strange.