Quantcast
Channel: ASPNETWebStack Issue Tracker Rss Feed
Viewing all 7215 articles
Browse latest View live

Commented Issue: [WebPages]: Update MimeMapping.cs to be match IIS8 applicationHost.config [1072]

$
0
0
The file was generated from the mimeMap in %System32%\inetsrv\config\applicationHost.config and it looks like IIS 8 has some slightly different mime mappings. It should probably be updated to match this file although the utility of it is highly questionable.
Comments: Adding more context for the bug: The WebPages’ “MimeMapping.cs” file is originally engineered based on the “ApplicationHost.config” file from IIS 7.5. The newly released IIS8.0 has some minor change in the ApplicationHost.config file which cause some mismatch entry from the MimeMapping.cs in WebPages. The usage that potentially would impact is the System.Web.Helper e.g. the System.Image class; the other possible usage is the WebPage Administration. The entry pointed out by the report is actually boils down to one line of code; the difference is listed below: From MimeMapping.cs: { ".js", "application/x-javascript" }, From the new ApplicationHost.config: <mimeMap fileExtension=".js" mimeType="application/javascript" />

Created Unassigned: Json.Encode doesn't encode array properties returned from Json.Decode [1085]

$
0
0
With this code:
```
var personJson = "{name:\"George\",aliases:[\"Peter\",\"David\"]}";
var person = Json.Decode(personJson);
person.name = "Michael";
personJson = Json.Encode(person);
```

Json.Encode is currently outputting:
```
"{\"name\":\"Michael\",\"aliases\":{}}"
```

When it should be:
```
"{\"name\":\"Michael\",\"aliases\":[\"Peter\",\"David\"]}"
```

The fix is in System.Web.Helpers/DynamicJavaScriptConverter.cs

```
// Get the value for each member in the dynamic object
foreach (string memberName in memberNames)
{
- values[memberName] = DynamicHelper.GetMemberValue(obj, memberName);
+ var value = DynamicHelper.GetMemberValue(obj, memberName);
+ if (value is DynamicJsonArray)
+ value = (object[])(DynamicJsonArray)value;
+ values[memberName] = value;
}

return values;
```

Commented Unassigned: Json.Encode doesn't encode array properties returned from Json.Decode [1085]

$
0
0
With this code:
```
var personJson = "{name:\"George\",aliases:[\"Peter\",\"David\"]}";
var person = Json.Decode(personJson);
person.name = "Michael";
personJson = Json.Encode(person);
```

Json.Encode is currently outputting:
```
"{\"name\":\"Michael\",\"aliases\":{}}"
```

When it should be:
```
"{\"name\":\"Michael\",\"aliases\":[\"Peter\",\"David\"]}"
```

The fix is in System.Web.Helpers/DynamicJavaScriptConverter.cs

```
// Get the value for each member in the dynamic object
foreach (string memberName in memberNames)
{
- values[memberName] = DynamicHelper.GetMemberValue(obj, memberName);
+ var value = DynamicHelper.GetMemberValue(obj, memberName);
+ if (value is DynamicJsonArray)
+ value = (object[])(DynamicJsonArray)value;
+ values[memberName] = value;
}

return values;
```
Comments: Just so you know a bug was filed by someone else on Microsoft Connect: http://connect.microsoft.com/VisualStudio/feedback/details/779119

Closed Issue: Html.EditorFor helper generates wrong date/time format [630]

$
0
0
In MVC applications, if someone uses the Html.EditorFor helper to generate UI for a model that includes a DateTime field, the resulting HTML markup will render a date in a culture format that doesn't resemble the one prescribed by the HTML 5 standard, which references RFC 3339.

To fix this, we need to change our generated markup to use one of the formats prescribed in the RFC.

Comments: Verified with the 5/30 build

Commented Unassigned: Global error handler for Web API [1001]

$
0
0
If my Web API application is going to return an error to a client, I want to know about it.

I want to set up something like ELMAH to notify me when the problem occurs, and I want full details of the error, including exception stack trace, logged on the server.

In MVC, the __Application_Error__ event is how you achive this, but in Web Api this event often isn't triggered because exceptions are converted into **HttpResponseMessage**s higher in the call stack, and because some error conditions create a **HttpResponseMessage** directly without using an exception. One source of this is __HttpControllerDispatcher.SendAsync__, which catches all exceptions and turns them into error responses, discarding the exception information.

Here are some examples of exceptions that I am interested in handling:

* Exceptions thrown from action methods and action filters
* Exceptions thrown when creating a controller instance
* Exceptions due to routing errors, bad requests, authentication problems, and invalid OData queries
* Exceptions thrown when an IQueryable returned by an action method fails to execute
* Exceptions thrown by custom message handlers and formatters

When I started using Web API, I was surprised when my __Application_Error__ handler did not pick up an action method exception. I added a global __ExceptionFilterAttribute__ to take care of that, but then found several other categories of errors that could be returned to the client and still leave silence in the server logs.

In a production environment, relying on clients to report errors and having no error information available on the server will make diagnosing problems reactive and difficult.

Please provide a global error handling event for Web API, so that error details can be logged and notifications sent. The event should provide access to unhandled exceptions and non-success **HttpResponseException**s and **HttpResponseMessage**s. In the case of **HttpError** objects created from an exception, the exception details should be retained for the error handling event.
Comments: For those looking for workarounds until this gets implemented, I just found "[Exception Handling for Web API Controller Constructors](http://blog.greatrexpectations.com/2013/05/15/exception-handling-for-web-api-controller-constructors/)" to deal with the second bullet point in this issue.

Closed Issue: EditorFor a Date emits Improper HTML 5 [629]

$
0
0
We’re building a new ASP.NET MVC 4 application. We’ve noticed that when using the HtmlHelper EditorFor for a date in our model, the date is being rendered with dashes ('-') instead of forward slashed ('/'). The latter is the proper format for Dates in HTML 5 (http://www.w3.org/TR/html-markup/datatypes.html#form.data.date ).
Comments: duplicate of #630

Edited Issue: XmlMediaTypeFormatter reports that it can't serialize DataQuery with XmlSerializer [255]

$
0
0
If you set the default xmlmediatypeformatter to UseXmlSerializer, calls to CanWriteType with an instance of DataQuery<T> return false. This is usually triggered in a call to CreateResponse which then throws. DataQuery<T> is the concrete type that linq to sql implements IQueryable<T> with.

There's a branch in the implementation that seems to allow IQueryables for the datacontractserializer but only IEnumerables for the xml one.

If you subclass XmlMediaTypeFormatter and (for example) return true from CanWriteType, the underlying XmlSerializer writes the results back just fine.

Action methods that return IQueryable should be supported for both the data contract and xml serializers.

Commented Issue: XmlMediaTypeFormatter reports that it can't serialize DataQuery with XmlSerializer [255]

$
0
0
If you set the default xmlmediatypeformatter to UseXmlSerializer, calls to CanWriteType with an instance of DataQuery<T> return false. This is usually triggered in a call to CreateResponse which then throws. DataQuery<T> is the concrete type that linq to sql implements IQueryable<T> with.

There's a branch in the implementation that seems to allow IQueryables for the datacontractserializer but only IEnumerables for the xml one.

If you subclass XmlMediaTypeFormatter and (for example) return true from CanWriteType, the underlying XmlSerializer writes the results back just fine.

Action methods that return IQueryable should be supported for both the data contract and xml serializers.
Comments: I was unable to repro. Linq to SQL seems to be working fine with XmlSerializer in an end-to-end scenario.

Commented Issue: XmlMediaTypeFormatter reports that it can't serialize DataQuery with XmlSerializer [255]

$
0
0
If you set the default xmlmediatypeformatter to UseXmlSerializer, calls to CanWriteType with an instance of DataQuery<T> return false. This is usually triggered in a call to CreateResponse which then throws. DataQuery<T> is the concrete type that linq to sql implements IQueryable<T> with.

There's a branch in the implementation that seems to allow IQueryables for the datacontractserializer but only IEnumerables for the xml one.

If you subclass XmlMediaTypeFormatter and (for example) return true from CanWriteType, the underlying XmlSerializer writes the results back just fine.

Action methods that return IQueryable should be supported for both the data contract and xml serializers.
Comments: I also checked that the DataQuery type was specifically being used and that UseXmlSerializer was turned on.

Edited Issue: XmlMediaTypeFormatter reports that it can't serialize DataQuery with XmlSerializer [255]

$
0
0
If you set the default xmlmediatypeformatter to UseXmlSerializer, calls to CanWriteType with an instance of DataQuery<T> return false. This is usually triggered in a call to CreateResponse which then throws. DataQuery<T> is the concrete type that linq to sql implements IQueryable<T> with.

There's a branch in the implementation that seems to allow IQueryables for the datacontractserializer but only IEnumerables for the xml one.

If you subclass XmlMediaTypeFormatter and (for example) return true from CanWriteType, the underlying XmlSerializer writes the results back just fine.

Action methods that return IQueryable should be supported for both the data contract and xml serializers.

Edited Issue: [CORS] Preflight request failed when there's an HttpOptions route attribute [1050]

$
0
0
This is reported by a customer. See more details here: https://aspnetwebstack.codeplex.com/discussions/441725#editor
Repro attached.

Commented Issue: [CORS] Preflight request failed when there's an HttpOptions route attribute [1050]

$
0
0
This is reported by a customer. See more details here: https://aspnetwebstack.codeplex.com/discussions/441725#editor
Repro attached.
Comments: Fixed: http://aspnetwebstack.codeplex.com/SourceControl/changeset/fb78ccb7ffaad79bb61d8d58e25f69e7ec856bc0

Commented Feature: Add OData Function Support [881]

$
0
0
Just like with actions, please add support for OData Functions. These are easy to implement with WebApi but it is very difficult to advertise the functions in the metadata since webapi odata currently does not support them.

http://www.odata.org/media/30002/OData.html#functions
Comments: Any more information on this? Or an alternative solution in the meantime?

Commented Unassigned: Global error handler for Web API [1001]

$
0
0
If my Web API application is going to return an error to a client, I want to know about it.

I want to set up something like ELMAH to notify me when the problem occurs, and I want full details of the error, including exception stack trace, logged on the server.

In MVC, the __Application_Error__ event is how you achive this, but in Web Api this event often isn't triggered because exceptions are converted into **HttpResponseMessage**s higher in the call stack, and because some error conditions create a **HttpResponseMessage** directly without using an exception. One source of this is __HttpControllerDispatcher.SendAsync__, which catches all exceptions and turns them into error responses, discarding the exception information.

Here are some examples of exceptions that I am interested in handling:

* Exceptions thrown from action methods and action filters
* Exceptions thrown when creating a controller instance
* Exceptions due to routing errors, bad requests, authentication problems, and invalid OData queries
* Exceptions thrown when an IQueryable returned by an action method fails to execute
* Exceptions thrown by custom message handlers and formatters

When I started using Web API, I was surprised when my __Application_Error__ handler did not pick up an action method exception. I added a global __ExceptionFilterAttribute__ to take care of that, but then found several other categories of errors that could be returned to the client and still leave silence in the server logs.

In a production environment, relying on clients to report errors and having no error information available on the server will make diagnosing problems reactive and difficult.

Please provide a global error handling event for Web API, so that error details can be logged and notifications sent. The event should provide access to unhandled exceptions and non-success **HttpResponseException**s and **HttpResponseMessage**s. In the case of **HttpError** objects created from an exception, the exception details should be retained for the error handling event.
Comments: I agree - it is hard enough as it is doing web API stuff - any help most appreciated.

Edited Issue: Parse function in jquery.validate.unobtrusive.js performance improvement [308]

$
0
0
The jquery statement

$(selector).find(":input[data-val=true]").each(....) - line 173 jquery.validate.unobtrusive.js within the Parse(selector) method.

Provides better performance if it is re-written as a chained statement, oppose to as a single selector:
$(selector).find("input").filter["data-val=true]").each(..)

This is because it allows JQuery to use less of the Sizzle engine (which is known to be poor). On a large DOM, it has shown performance improvements of an order of magnitude firing the DOMContentLoaded event.

We have reduced the duration of our Document ready method from 700ms to 300ms.

Thanks,

Commented Unassigned: WebApi: Filters can't have a set execution order [1065]

$
0
0
MVC filter attributes support the Order property for setting the execution order when multiple instances are applied to a controller or method, those in Web API don't.
Comments: As a work around you can look into overriding GetFilterPipeLine in HttpActionDescriptor. ``` public override Collection<FilterInfo> GetFilterPipeline() { Collection<FilterInfo> originalFilters = _innerDescriptor.GetFilterPipeline(); Collection<FilterInfo> newFilters = new Collection<FilterInfo>(); // AS AN EXAMPLE, HERE IS HOW TO REPLACE A FILTER WITH YOUR OWN // SIMILARLY YOU CAN CHANGE THE ORDER // for any actions that support query composition, we need to replace it with our // query filter. foreach (FilterInfo filterInfo in originalFilters) { FilterInfo newInfo = filterInfo; QueryableAttribute queryableFilter = filterInfo.Instance as QueryableAttribute; if (queryableFilter != null) { newInfo = new FilterInfo(new QueryFilterAttribute() { ResultLimit = queryableFilter.ResultLimit }, filterInfo.Scope); } newFilters.Add(newInfo); } return newFilters; } ```

Closed Issue: Bundler / minifier not handling end of file comments correctly [884]

$
0
0
I have noticed that the bundler doesn't handle single line comments at the end of a javascript file correctly (or as would be expected), when the script is bundled and minified.

A single line comment at the end of one of the script files, without a line break at the end, affects the content/interpretation of the script of the next file.

Suppose script 1 has:

```
var hello = "Hello";

function SayHelloWorld() {
alert(hello + "World");
}

//=======test comment==========(no line break here)
```

and script two has:

```
function Test()
{
this.a = 1;
}

//===== another comment with no line break at the end=======
```

The resulting script after bundling is:

```
function SayHelloWorld(){alert(hello+"World")}var hello="Hello";this.a=1
```
Notice that constructor function Test() has disappeared and only the contents of that function are placed on the resulting script;

Removing the comment at the end of the file, or adding a line break after it outputs the correct and expected script

```
function SayHelloWorld(){alert(hello+"World")}function Test(){this.a=1}var hello="Hello"
```


about the attatchment: I includes a Bundle.cs (with the bundle definition), the javascript files in the script/testscripts directory, and a modified _layout to include the bundle. This can be copied onto a simple MVC4 internet Application project.

Comments: Hello, and thank you for the bug report. I talked to the developer of that project and he says this bug is fixed in v1.1 Beta 1, which is available on NuGet: http://nuget.org/packages/Microsoft.AspNet.Web.Optimization/1.1.0-Beta1

Commented Issue: [WebApiOnOwin]Uploading a 2GB file with custom input buffer selector set to true fails [1036]

$
0
0
Repro sample : FileUploadSample (file://KK-MC2/FileUploadSample)

I have a simple custom buffer selector where UseBufferedInputStream returns true.

When I try to upload a 2GB fails, I am seeing a failure with below stack trace.

{"The stream does not support concurrent IO read or write operations."}

at System.Net.ConnectStream.InternalWrite(Boolean async, Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
at System.Net.ConnectStream.BeginWrite(Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
at System.Net.Http.StreamToStreamCopy.TryStartWriteSync(Int32 bytesRead)
at System.Net.Http.StreamToStreamCopy.BufferReadCallback(IAsyncResult ar)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at FileUploadSample.Program.<RunClient>d__0.MoveNext() in e:\TestProjects\FileUploadSample\Program.cs:line 72
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<ThrowAsync>b__1(Object state)
at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()






Comments: A couple notes here: 1) This isn't a valid user scenario. No one should be buffering a 2GB request body. 2) The exception that appears above is a stack trace for the client, not the server. I'm unable to repro the client issue, but it would be a problem with HttpClient and not Web API or OWIN. 3) I'm noticing a weird behavior though where even when an OutOfMemoryException gets thrown, the OWIN HttpListener server fully drains the request body before sending back a 500. This seems like it could expose users to a potential denial of service attack. I'll follow up with the Katana team.

Closed Issue: [WebApiOnOwin]Uploading a 2GB file with custom input buffer selector set to true fails [1036]

$
0
0
Repro sample : FileUploadSample (file://KK-MC2/FileUploadSample)

I have a simple custom buffer selector where UseBufferedInputStream returns true.

When I try to upload a 2GB fails, I am seeing a failure with below stack trace.

{"The stream does not support concurrent IO read or write operations."}

at System.Net.ConnectStream.InternalWrite(Boolean async, Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
at System.Net.ConnectStream.BeginWrite(Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
at System.Net.Http.StreamToStreamCopy.TryStartWriteSync(Int32 bytesRead)
at System.Net.Http.StreamToStreamCopy.BufferReadCallback(IAsyncResult ar)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at FileUploadSample.Program.<RunClient>d__0.MoveNext() in e:\TestProjects\FileUploadSample\Program.cs:line 72
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<ThrowAsync>b__1(Object state)
at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()






Edited Issue: [WebApiOnOwin]Uploading a 2GB file with custom input buffer selector set to true fails [1036]

$
0
0
Repro sample : FileUploadSample (file://KK-MC2/FileUploadSample)

I have a simple custom buffer selector where UseBufferedInputStream returns true.

When I try to upload a 2GB fails, I am seeing a failure with below stack trace.

{"The stream does not support concurrent IO read or write operations."}

at System.Net.ConnectStream.InternalWrite(Boolean async, Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
at System.Net.ConnectStream.BeginWrite(Byte[] buffer, Int32 offset, Int32 size, AsyncCallback callback, Object state)
at System.Net.Http.StreamToStreamCopy.TryStartWriteSync(Int32 bytesRead)
at System.Net.Http.StreamToStreamCopy.BufferReadCallback(IAsyncResult ar)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at FileUploadSample.Program.<RunClient>d__0.MoveNext() in e:\TestProjects\FileUploadSample\Program.cs:line 72
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<ThrowAsync>b__1(Object state)
at System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()






Viewing all 7215 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>