Incorrect Content-Length Header Causes Request Cancellation

[biscuitWizard]

Prerequisites

• [x] I have written a descriptive issue title
• [x] I have verified that I am running the latest version of Nancy
• [x] I have verified if the problem exist in both DEBUG and RELEASE mode
• [x] I have searched open and closed issues to ensure it has not already been reported

Description

If Content-Length is set to an incorrect number on purpose (IE: Not matching content body length) the Pipeline fails with exception:

42568  [             38] ERROR                        Program (null) - Unhandled
 Exception Caught in NancyFX
System.Net.HttpListenerException (0x80004005): An operation was attempted on a n
onexistent network connection
   at System.Net.HttpRequestStream.BeginRead(Byte[] buffer, Int32 offset, Int32
size, AsyncCallback callback, Object state)
   at Nancy.Extensions.StreamExtensions.CopyTo(Stream source, Stream destination
, Action`3 onComplete)
   at Nancy.IO.RequestStream.MoveToWritableStream()
   at Nancy.IO.RequestStream..ctor(Stream stream, Int64 expectedLength, Int64 th
resholdLength, Boolean disableStreamSwitching)
   at Nancy.Hosting.Self.NancyHost.ConvertRequestToNancyRequest(HttpListenerRequ
est request)
   at Nancy.Hosting.Self.NancyHost.Process(HttpListenerContext ctx)

before even reaching the BeforeRequest pipeline hooks. This is a concern because in cases where the two do not match (Example: During 29%~ Packet Loss, actual content stream malformation) it is impossible to deal with and recover from this issue.

Steps to Reproduce

1. Create a simple route in NancyFX
2. Make a request to that route with some sample data in the body, and a random content-length.
3. Observe OnError thrown in the pipeline

System Configuration

• Nancy version: 1.4.1
• Nancy host
  • [ ] ASP.NET
  • [ ] OWIN
  • [X] Self-Hosted
• Other Nancy packages and versions:
• Environment (Operating system, version and so on): windows 8.1, windows 10
• .NET Framework version: 4.5
• Additional information:

[S1r-Lanzelot]

Should this be supported? Some argue not... https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html in rules 4.4 (as referenced in 14.14) I believe that a proper notification should be sent. Regardless, the error should be handled more gracefully it seems. Thoughts?

[thecodejunkie]

Yeah, I think we should validate it against he stream length. Either of you care to send a PR and I'll review?

[S1r-Lanzelot]

Ya I can look into this, I just want to replicate it on my machine first.

[S1r-Lanzelot]

@thecodejunkie, so you're thinking of just reading the stream byte by byte to figure out the length in order to validate it?

I am running into a wall with validating because the InputStream off of the HttpListenerContext is not seekable thus I cannot access length. Copying this Stream instance to a MemoryStream will throw the same error and reading the stream to the end has the same outcome as it is using the content-length I believe. Thoughts? Thanks.

[diegodfsd]

Some news about this problem?