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

Commented Issue: Helpage UI to show the root request url path [1153]

July 22, 2013, 1:14 pm
$
0
0
A very minor user experience issue.

For the following controller:
```
[RoutePrefix("api/values")]
public class ValuesController : ApiController
{
[HttpGet("")]
[HttpGet("/")]
public IEnumerable<string> GetAll()
{
return new string[] { "value1", "value2" };
}
}
```
There would be 2 routes like below:
1. config.Routes.MapHttpRoute("routeName", "", new { }, new { httpMethod = HttpMethodConstraints[GET] }, new { actions = [Values.GetAll()] });
2. config.Routes.MapHttpRoute("routeName", "api/values", new { }, new { httpMethod = HttpMethodConstraints[GET] }, new { actions = [Values.GetAll()] });

__Issue__:
For the route '1', HelpPage UI says "GET". (__attached__ snapshot).

It would be clear if it said "GET /"
Comments: It's not a very common scenario to have an API at the root, so we'll consider this in vNext.
↧
Search

Edited Issue: In web api attribute routing, force users to supply HttpVerbAttribute base routetemplates on actions, if controller is decorated with RoutePrefix [1152]

July 22, 2013, 1:16 pm
$
0
0
__For the following case__:
```
[RoutePrefix("api/values")]
public class ValuesController : ApiController
{
public IEnumerable<string> GetAllValues()
{
return new string[] { "value1", "value2" };
}
}
```
Following is how the route looks like(_note_ that there are no httpMethod route constraints):
config.Routes.MapHttpRoute("routeName", "api/values", new { }, new { }, new { actions = [Values.GetAllValues()] });

__Reasons for this ask__:
1. In the above scenario, appropriate method constraint is not being added to the route.
2. Keeping the behavior consistent with how MVC attribute routing does, which is, it does not add any route to the collection if an action is not decorated with the verb attribute.
3. Also, I am seeing a NullRef exception when the controller looks like below:
```
RoutePrefix("api/values")]
public class ValuesController : ApiController
{
public IEnumerable<string> GetAllValues()
{
return new string[] { "value1", "value2" };
}

public string GetSingle(int id)
{
return "value";
}
}
```

__Exception__:
[NullReferenceException: Object reference not set to an instance of an object.]
System.Web.Http.HttpConfigurationExtensions.CreateRouteEntries(HttpControllerDescriptor controllerDescriptor) in c:\WebstackRuntime\Runtime\src\System.Web.Http\HttpConfigurationExtensions.cs:164
System.Web.Http.HttpConfigurationExtensions.MapHttpAttributeRoutes(HttpConfiguration configuration, HttpRouteBuilder routeBuilder) in c:\WebstackRuntime\Runtime\src\System.Web.Http\HttpConfigurationExtensions.cs:91
System.Web.Http.HttpConfigurationExtensions.MapHttpAttributeRoutes(HttpConfiguration configuration) in c:\WebstackRuntime\Runtime\src\System.Web.Http\HttpConfigurationExtensions.cs:63
MvcAppSample.WebApiConfig.Register(HttpConfiguration config) in c:\Users\kichalla\Documents\Visual Studio 2013\Projects\MvcAppSample\App_Start\WebApiConfig.cs:17
MvcAppSample.MvcApplication.Application_Start() in c:\Users\kichalla\Documents\Visual Studio 2013\Projects\MvcAppSample\Global.asax.cs:21
↧
↧

Commented Issue: In web api attribute routing, force users to supply HttpVerbAttribute base routetemplates on actions, if controller is decorated with RoutePrefix [1152]

July 22, 2013, 1:16 pm
$
0
0
__For the following case__:
```
[RoutePrefix("api/values")]
public class ValuesController : ApiController
{
public IEnumerable<string> GetAllValues()
{
return new string[] { "value1", "value2" };
}
}
```
Following is how the route looks like(_note_ that there are no httpMethod route constraints):
config.Routes.MapHttpRoute("routeName", "api/values", new { }, new { }, new { actions = [Values.GetAllValues()] });

__Reasons for this ask__:
1. In the above scenario, appropriate method constraint is not being added to the route.
2. Keeping the behavior consistent with how MVC attribute routing does, which is, it does not add any route to the collection if an action is not decorated with the verb attribute.
3. Also, I am seeing a NullRef exception when the controller looks like below:
```
RoutePrefix("api/values")]
public class ValuesController : ApiController
{
public IEnumerable<string> GetAllValues()
{
return new string[] { "value1", "value2" };
}

public string GetSingle(int id)
{
return "value";
}
}
```

__Exception__:
[NullReferenceException: Object reference not set to an instance of an object.]
System.Web.Http.HttpConfigurationExtensions.CreateRouteEntries(HttpControllerDescriptor controllerDescriptor) in c:\WebstackRuntime\Runtime\src\System.Web.Http\HttpConfigurationExtensions.cs:164
System.Web.Http.HttpConfigurationExtensions.MapHttpAttributeRoutes(HttpConfiguration configuration, HttpRouteBuilder routeBuilder) in c:\WebstackRuntime\Runtime\src\System.Web.Http\HttpConfigurationExtensions.cs:91
System.Web.Http.HttpConfigurationExtensions.MapHttpAttributeRoutes(HttpConfiguration configuration) in c:\WebstackRuntime\Runtime\src\System.Web.Http\HttpConfigurationExtensions.cs:63
MvcAppSample.WebApiConfig.Register(HttpConfiguration config) in c:\Users\kichalla\Documents\Visual Studio 2013\Projects\MvcAppSample\App_Start\WebApiConfig.cs:17
MvcAppSample.MvcApplication.Application_Start() in c:\Users\kichalla\Documents\Visual Studio 2013\Projects\MvcAppSample\Global.asax.cs:21
Comments: The null ref exception is obviously a bug. For the other part of the issue description we should figure out what the correct behavior should be.
↧

Edited Issue: Web Api attribute routing is adding NonAction decorated method to route collection [1151]

July 22, 2013, 1:20 pm
$
0
0
__Scenario__:
A user sometimes would like to keep some methods public in his controller but would not like it to be invoked by end users, so he decorates it with [NonAction] attribute.

__Issue__:
In the following scenario, a route is being added to the route collection:
```
[RoutePrefix("api/values")]
public class ValuesController : ApiController
{
[NonAction]
public IEnumerable<string> GetAllValues()
{
return new string[] { "value1", "value2" };
}
}
```
Following would be how the route could look like in the route collection:
config.Routes.MapHttpRoute("routeName", "api/values", new { }, new { }, new { actions = [Values.GetAllValues()] });

__Workaround__:
Create custom route builder deriving from the default one. Override one of the "BuildHttpRoute" methods which provides access to the action descriptor and using it you can check to see if there are any NonAction attributes decorated and if present, ignore adding the route to the route collection.

__UPDATE__:
I have tried the above workaround, but I am currently receiving an exception. __Should we allow returning null from route builder?__ I cannot think of other scenarios where users might want to do this.

```
public override IHttpRoute BuildHttpRoute(string routeTemplate, IEnumerable<HttpMethod> httpMethods,
IEnumerable<ReflectedHttpActionDescriptor> actions)
{
ReflectedHttpActionDescriptor nonActionDescriptor = actions.FirstOrDefault();

if (nonActionDescriptor != null)
{
Collection<NonActionAttribute> nonActionAttribs = nonActionDescriptor.GetCustomAttributes<NonActionAttribute>(inherit: false);

if (nonActionAttribs.Count > 0)
{
return null;
}
}

return base.BuildHttpRoute(routeTemplate, httpMethods, actions);
}
```

__Exception__:
System.ArgumentNullException occurred
HResult=-2147467261
Message=Value cannot be null.
Parameter name: route
Source=System.Web.Http
ParamName=route
StackTrace:
at System.Web.Http.HttpRouteCollection.Add(String name, IHttpRoute route) in c:\WebstackRuntime\Runtime\src\System.Web.Http\HttpRouteCollection.cs:line 167
InnerException:

↧

Commented Issue: Web Api attribute routing is adding NonAction decorated method to route collection [1151]

July 22, 2013, 1:20 pm
$
0
0
__Scenario__:
A user sometimes would like to keep some methods public in his controller but would not like it to be invoked by end users, so he decorates it with [NonAction] attribute.

__Issue__:
In the following scenario, a route is being added to the route collection:
```
[RoutePrefix("api/values")]
public class ValuesController : ApiController
{
[NonAction]
public IEnumerable<string> GetAllValues()
{
return new string[] { "value1", "value2" };
}
}
```
Following would be how the route could look like in the route collection:
config.Routes.MapHttpRoute("routeName", "api/values", new { }, new { }, new { actions = [Values.GetAllValues()] });

__Workaround__:
Create custom route builder deriving from the default one. Override one of the "BuildHttpRoute" methods which provides access to the action descriptor and using it you can check to see if there are any NonAction attributes decorated and if present, ignore adding the route to the route collection.

__UPDATE__:
I have tried the above workaround, but I am currently receiving an exception. __Should we allow returning null from route builder?__ I cannot think of other scenarios where users might want to do this.

```
public override IHttpRoute BuildHttpRoute(string routeTemplate, IEnumerable<HttpMethod> httpMethods,
IEnumerable<ReflectedHttpActionDescriptor> actions)
{
ReflectedHttpActionDescriptor nonActionDescriptor = actions.FirstOrDefault();

if (nonActionDescriptor != null)
{
Collection<NonActionAttribute> nonActionAttribs = nonActionDescriptor.GetCustomAttributes<NonActionAttribute>(inherit: false);

if (nonActionAttribs.Count > 0)
{
return null;
}
}

return base.BuildHttpRoute(routeTemplate, httpMethods, actions);
}
```

__Exception__:
System.ArgumentNullException occurred
HResult=-2147467261
Message=Value cannot be null.
Parameter name: route
Source=System.Web.Http
ParamName=route
StackTrace:
at System.Web.Http.HttpRouteCollection.Add(String name, IHttpRoute route) in c:\WebstackRuntime\Runtime\src\System.Web.Http\HttpRouteCollection.cs:line 167
InnerException:

Comments: Hmm this looks kind of bad. I guess the question is perhaps firstly why is there even an HttpActionDescriptor for the NonAction-decorated method, or at least, if there is supposed to be one, should it be annotated as not being an action? I would expect that there probably shouldn't be a descriptor at all, and then we won't walk it to begin with.
↧
↧

Edited Feature: Mvc attribute routing should provide a way to create custom routes and constaints. [1149]

July 22, 2013, 1:21 pm
$
0
0
__Scenario__:
User would like to create domain-specific custom routes or add constraints to a route (_note_: not inline constraint) before its added to the route collection.

__Issue__:
Mvc attribute routing extension currently does not provide a way to supply custom RouteBuilder which can be used to perform the above scenario.

__Reason__:
Creating custom routes (domain specific, for example) or custom constraints seem to be a valid scenario, if not common. I think we should provide a way for end users to do this. Currently Web API's extension accepts a HttpRouteBuilder. Also, we need to provide a consistent user experience across MVC and Web API.

The current extensions on MVC attribute routing are:

public static void MapMvcAttributeRoutes(this RouteCollection routes)
public static void MapMvcAttributeRoutes(this RouteCollection routes, IInlineConstraintResolver constraintResolver)
public static void MapMvcAttributeRoutes(this RouteCollection routes, IEnumerable<Type> controllerTypes)
public static void MapMvcAttributeRoutes(this RouteCollection routes, IEnumerable<Type> controllerTypes, IInlineConstraintResolver constraintResolver)
↧

Edited Unassigned: Hiding controller from showing up on HelpPage does not work when attribute routing is used [1148]

July 22, 2013, 1:22 pm
$
0
0
__Scenario__:
User does not like to show up a controller on HelpPage (ex: EntitySetController in OData), so he would like to use setting like [ApiExplorerSettings(IgnoreApi=true)] on the controller.

__Issue__:
When AR is used, [ApiExplorerSettings(IgnoreApi=true)] on the controller is not being honored and HelpPage shows the controller. This is however not a problem when conventional routing is used though.

__Reason__:
With latest checkin related to bug # 1125, when ApiExplorer tries to generate descriptions it goes through different path for AR generated routes than conventional routes.

__Workarounds__:
1. A user could set [ApiExplorerSettings(IgnoreApi=true)] on each individual action which can make the whole controller to not show up.
2. A custom ApiExplorer deriving from the default and overriding the method "public override bool ShouldExploreAction(string actionVariableValue, HttpActionDescriptor actionDescriptor, IHttpRoute route)". This method would get called for every action that is going to be explored. One could check the controller name type from the supplied action descriptor and return 'false' for the ones not interested.

Attached a standalone katana selfhost repro.
Expected: "api descriptions count: 0"
Actual: "api descriptions count: 1"
↧

Closed Unassigned: Resource not found when consumer uses matrix parameters, but aren't defined in Web API [1147]

July 22, 2013, 1:27 pm
$
0
0
Hey guys,

Code example:
```
/// <summary>
/// Get customers.
/// </summary>
[HttpGet("api/customers")]
public IEnumerable<Customer> GetCustomers()
{
...
}
```

When a consumer/client requests the defined route normally (http://mydomain.com/api/customers), he will get a result. But in case the consumer/client puts matrix parameters after the URI (http://mydomain.com/api/customers;name=John;surname=Bishop) then he will get a "404 Resource cannot be found".

I know that i can define these matrix parameters in the HttpGet attribute, but thats not the problem. The consumer/client should get the right response, whether the matrix parameters are defined or not in the HttpGet attribute.
So I think this is a bug, because matrix parameters aren't part of the resourcename, they are normal parameters like query params (?param1=value&param2=value).

Kind regards,
Andy
Comments: Hi, We are not planning to add built-in support for matrix parameters in Web API because it causes ambiguity in URIs. If the route template has the template options explicitly listed then it should work, but of course you'd have to add every combination of parameters. This can all be implemented with a custom route (e.g. deriving from HttpRoute), but that is admittedly somewhat difficult. Thanks, Eilon
↧
Search

Edited Issue: MVC attribute routing fails for multiple routes with the same URL, and no specific RouteName set. [1146]

July 22, 2013, 1:31 pm
$
0
0
__Scenario__:
User decorates the controller and actions with attributed routes and expects the applicaiton to work.

__Issue__:
Consider the following two actions in AccountController(shortened for brevity):
```
[RoutePrefix("Account")]
public class AccountController : Controller
{
//
// GET: /Account/Register
[AllowAnonymous]
[HttpGet("Register")]
public ActionResult Register()


//
// POST: /Account/Register
[HttpPost("Register")]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Register(RegisterViewModel model)
}
```
After the above changes, when the application is launched, we currently get the following
__Error__:
"A route named 'Account/Register' is already in the route collection. Route names must be unique.
Parameter name: name"

__Expected__:
The above error should not be occuring and the application should be launched successfully.

__Reason__:
In MVC, it appears that most of the Url link generation happens via the "Url.Action" or "Html.Actionlink" helpers, where users can specify action name, controller name etc. Since these helpers are used more commonly than "Url.RouteUrl" which expects a route name, we should not force the users to supply a unique route name upfront. We should generate unique names automatically just like how Web API's attribute routing works.

Even in Web API, we do not expect the users to depend on our uniquely generated names to generate links. If indeed they would like to have a friendly name for a particular route, they are expected to explicitly supply them. This way at least we do not provide a bad user experience upfront like currently MVC attribute routing does.

↧
↧

Commented Issue: MVC attribute routing fails for multiple routes with the same URL, and no specific RouteName set. [1146]

July 22, 2013, 1:31 pm
$
0
0
__Scenario__:
User decorates the controller and actions with attributed routes and expects the applicaiton to work.

__Issue__:
Consider the following two actions in AccountController(shortened for brevity):
```
[RoutePrefix("Account")]
public class AccountController : Controller
{
//
// GET: /Account/Register
[AllowAnonymous]
[HttpGet("Register")]
public ActionResult Register()


//
// POST: /Account/Register
[HttpPost("Register")]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Register(RegisterViewModel model)
}
```
After the above changes, when the application is launched, we currently get the following
__Error__:
"A route named 'Account/Register' is already in the route collection. Route names must be unique.
Parameter name: name"

__Expected__:
The above error should not be occuring and the application should be launched successfully.

__Reason__:
In MVC, it appears that most of the Url link generation happens via the "Url.Action" or "Html.Actionlink" helpers, where users can specify action name, controller name etc. Since these helpers are used more commonly than "Url.RouteUrl" which expects a route name, we should not force the users to supply a unique route name upfront. We should generate unique names automatically just like how Web API's attribute routing works.

Even in Web API, we do not expect the users to depend on our uniquely generated names to generate links. If indeed they would like to have a friendly name for a particular route, they are expected to explicitly supply them. This way at least we do not provide a bad user experience upfront like currently MVC attribute routing does.

Comments: As long as we're reasonably consistent between Web API and MVC attribute routing I'm fine with it. Of course, Web API _requires_ route names, so maybe some small (but reasonable) discrepancies are acceptable.
↧

Edited Unassigned: Support ODataMediaTypeFormatter usage by HttpClient [1140]

July 22, 2013, 1:31 pm
$
0
0
My company expects to implement IIS hosted Web APIs that run on app servers. These will be called by IIS hosted web applications that run on web servers.

We can therefore use ApiControllers on the app servers and call them from HttpClient from the web servers. I like this programming model, where we use the same MediaTypeFormatter and extensibility points at both ends of the wire.

We expect to use EntitySetController endpoints wherever we can, for general CRUD operations, using the JSON light format. Then fall back to ApiControllers if we have to - for operations like IN queries that OData doesn't support.

Ideally I'd like to be able to the following. These may need to use different wire formats (maybe JSON.Net and JSON light). However, I don't want to have to use a DataServiceContext to call EntitySetController, since supporting two entirely different client side programming models adds a lot of work.

* Use the HttpClient to talk to an ApiController
* Use the HttpClient to talk to an EntitySetController

I think I'm right in saying that the second case requires the client to use the ODataMediaTypeFormatter, and the client needs to provide an IEdmModel via the HttpRequestMessage.SetEdmModel method. However, I've been unable to get this to work, with various formatter / serialization problems.

If this supported currently, and if so can anyone point me to some sample code? Any help appreciated.
↧

Closed Unassigned: ObjectContent.Value to return T not object [1137]

July 22, 2013, 1:36 pm
$
0
0
Currently `ObjectContext<T>` returns `base.Value` which has type `object`.
Doesn't it make sense to introduce strongly-typed property to return `T` ( and change how is being kept internally)?
Comments: Hi, Thank you for clarifying the scenario. After further investigation we're not sure that this change can be done anyway due to a different change to ObjectContent. We made a change not too long ago where the "T" being stored inside the ObjectContent doesn't always exactly match what was initially set. This happens in OData query scenarios where sometimes the entity (e.g. "Customer") needs to be wrapped in a container type such as SingleResult<T>. As such, having a true strongly-typed "Value" property would not work all the time because the SingleResult<T> would not derive from "T". Thanks, Eilon
↧

Edited Issue: In web api attribute routing, force users to supply HttpVerbAttribute base routetemplates on actions, if controller is decorated with RoutePrefix [1152]

July 22, 2013, 6:03 pm
$
0
0
__For the following case__:
```
[RoutePrefix("api/values")]
public class ValuesController : ApiController
{
public IEnumerable<string> GetAllValues()
{
return new string[] { "value1", "value2" };
}
}
```
Following is how the route looks like(_note_ that there are no httpMethod route constraints):
config.Routes.MapHttpRoute("routeName", "api/values", new { }, new { }, new { actions = [Values.GetAllValues()] });

__Reasons for this ask__:
1. In the above scenario, appropriate method constraint is not being added to the route.
2. Keeping the behavior consistent with how MVC attribute routing does, which is, it does not add any route to the collection if an action is not decorated with the verb attribute.
3. Also, I am seeing a NullRef exception when the controller looks like below:
```
RoutePrefix("api/values")]
public class ValuesController : ApiController
{
public IEnumerable<string> GetAllValues()
{
return new string[] { "value1", "value2" };
}

public string GetSingle(int id)
{
return "value";
}
}
```

__Exception__:
[NullReferenceException: Object reference not set to an instance of an object.]
System.Web.Http.HttpConfigurationExtensions.CreateRouteEntries(HttpControllerDescriptor controllerDescriptor) in c:\WebstackRuntime\Runtime\src\System.Web.Http\HttpConfigurationExtensions.cs:164
System.Web.Http.HttpConfigurationExtensions.MapHttpAttributeRoutes(HttpConfiguration configuration, HttpRouteBuilder routeBuilder) in c:\WebstackRuntime\Runtime\src\System.Web.Http\HttpConfigurationExtensions.cs:91
System.Web.Http.HttpConfigurationExtensions.MapHttpAttributeRoutes(HttpConfiguration configuration) in c:\WebstackRuntime\Runtime\src\System.Web.Http\HttpConfigurationExtensions.cs:63
MvcAppSample.WebApiConfig.Register(HttpConfiguration config) in c:\Users\kichalla\Documents\Visual Studio 2013\Projects\MvcAppSample\App_Start\WebApiConfig.cs:17
MvcAppSample.MvcApplication.Application_Start() in c:\Users\kichalla\Documents\Visual Studio 2013\Projects\MvcAppSample\Global.asax.cs:21
↧
↧

Commented Issue: In web api attribute routing, force users to supply HttpVerbAttribute base routetemplates on actions, if controller is decorated with RoutePrefix [1152]

July 22, 2013, 6:03 pm
$
0
0
__For the following case__:
```
[RoutePrefix("api/values")]
public class ValuesController : ApiController
{
public IEnumerable<string> GetAllValues()
{
return new string[] { "value1", "value2" };
}
}
```
Following is how the route looks like(_note_ that there are no httpMethod route constraints):
config.Routes.MapHttpRoute("routeName", "api/values", new { }, new { }, new { actions = [Values.GetAllValues()] });

__Reasons for this ask__:
1. In the above scenario, appropriate method constraint is not being added to the route.
2. Keeping the behavior consistent with how MVC attribute routing does, which is, it does not add any route to the collection if an action is not decorated with the verb attribute.
3. Also, I am seeing a NullRef exception when the controller looks like below:
```
RoutePrefix("api/values")]
public class ValuesController : ApiController
{
public IEnumerable<string> GetAllValues()
{
return new string[] { "value1", "value2" };
}

public string GetSingle(int id)
{
return "value";
}
}
```

__Exception__:
[NullReferenceException: Object reference not set to an instance of an object.]
System.Web.Http.HttpConfigurationExtensions.CreateRouteEntries(HttpControllerDescriptor controllerDescriptor) in c:\WebstackRuntime\Runtime\src\System.Web.Http\HttpConfigurationExtensions.cs:164
System.Web.Http.HttpConfigurationExtensions.MapHttpAttributeRoutes(HttpConfiguration configuration, HttpRouteBuilder routeBuilder) in c:\WebstackRuntime\Runtime\src\System.Web.Http\HttpConfigurationExtensions.cs:91
System.Web.Http.HttpConfigurationExtensions.MapHttpAttributeRoutes(HttpConfiguration configuration) in c:\WebstackRuntime\Runtime\src\System.Web.Http\HttpConfigurationExtensions.cs:63
MvcAppSample.WebApiConfig.Register(HttpConfiguration config) in c:\Users\kichalla\Documents\Visual Studio 2013\Projects\MvcAppSample\App_Start\WebApiConfig.cs:17
MvcAppSample.MvcApplication.Application_Start() in c:\Users\kichalla\Documents\Visual Studio 2013\Projects\MvcAppSample\Global.asax.cs:21
Comments: Fixed: https://aspnetwebstack.codeplex.com/SourceControl/changeset/f827886fbfff38a8932a29f5018e3223c0e98d10
↧

Edited Issue: Request correlation Guid should use existing one if present [1133]

July 22, 2013, 6:12 pm
$
0
0
HttpRequestMessageExtensions.GetCorrelationId() creates a new Guid and stores it as a property in the request. Tracing uses this ID to correlate all traces within a common request. ETW-based tracers are encouraged to write this same ID to System.Diagnostics.Trace.CorrelationManager.ActivityId so that ETW uses the same ID WebAPI does.

But when running web-hosted, ASP.NET effectively owns the ActivityID stored in the current CallContext and will always overwrite WebApi's anytime an 'await' is used to wait for a Task to complete. Customers have reported that exception filters and action filters get the wrong ActivityId -- it is because ASP.NET has overwritten WebApi's in the continuation of the Task that invoked the action. This happens in RTM as well as the 5.2 beta.

The advice from ASP.NET is for WebAPI (and customers) to use the existing ActivityId and not try to create one.

To fix this issue, HttpRequestMessageExtensions.GetCorrelationId should first check whether Trace.CorrelationManager.ActivityId has been set. If so, it should use it rather than Guid.NewGuid().
↧
Search

Commented Issue: Request correlation Guid should use existing one if present [1133]

July 22, 2013, 6:12 pm
$
0
0
HttpRequestMessageExtensions.GetCorrelationId() creates a new Guid and stores it as a property in the request. Tracing uses this ID to correlate all traces within a common request. ETW-based tracers are encouraged to write this same ID to System.Diagnostics.Trace.CorrelationManager.ActivityId so that ETW uses the same ID WebAPI does.

But when running web-hosted, ASP.NET effectively owns the ActivityID stored in the current CallContext and will always overwrite WebApi's anytime an 'await' is used to wait for a Task to complete. Customers have reported that exception filters and action filters get the wrong ActivityId -- it is because ASP.NET has overwritten WebApi's in the continuation of the Task that invoked the action. This happens in RTM as well as the 5.2 beta.

The advice from ASP.NET is for WebAPI (and customers) to use the existing ActivityId and not try to create one.

To fix this issue, HttpRequestMessageExtensions.GetCorrelationId should first check whether Trace.CorrelationManager.ActivityId has been set. If so, it should use it rather than Guid.NewGuid().
Comments: Fixed: https://aspnetwebstack.codeplex.com/SourceControl/changeset/9d727873a003cf947f9c88e6d672fe4dcb8e4a9a
↧

Created Feature: Add JSONP support in WebAPI [1157]

July 22, 2013, 11:00 pm
$
0
0
We added CORS support in WebAPI but most browsers don't have support for CORS so supporting JSONP will still be valuable. I am opening this bug in codeplex here so we can track this work.
↧
↧

Created Unassigned: RouteData not available to WebHost's buffer policy selector for attribute routing generated routes [1158]

July 23, 2013, 12:35 am
$
0
0
__Scenario__:
User wishes to upload large files to a Web API service. He does not want these files to be buffered, so depending on the incoming request's route data (ex: controller, action), he either enables streamed or buffer mode.

__Issue__:
In the below code, "UserBufferInputStream" method isn't having any routedata available to perform the evaluation. This happens only for attribute routing generated routes as it goes through a certain path which conventional routes do not go through.

```
config.Services.Replace(typeof(IHostBufferPolicySelector), new CustomWebHostBufferPolicySelector());

public class CustomWebHostBufferPolicySelector : WebHostBufferPolicySelector
{
public override bool UseBufferedInputStream(object hostContext)
{
HttpContextBase contextBase = (HttpContextBase)hostContext;

RouteData routeData = contextBase.Request.RequestContext.RouteData;

object actions;
if (routeData.DataTokens != null && routeData.DataTokens.TryGetValue("actions", out actions))
{
//retrieve the controller name from action descriptors
}

return true;
}
}

```
↧

Created Unassigned: Razor V2 & V3-beta2 : Issue with parsing bool value in HTML tag attribute [1159]

July 23, 2013, 4:47 am
$
0
0
From Razor V2 onwards, I have noticed issue while parsing bool value with HTML tag attribute. Issue reproduced only when we are parsing bool value as HTML tag attribute. Please have a look at below code snippet and output i.e. rendered HTML.

__Code Snippet__
@{
bool trueVal = true;
bool falseVal = false;
}
@trueVal | @falseVal | <input type="text" value="@trueVal" /> | <input type="text" value="@falseVal" />

__Razor V1 Output__
True | False | <input type="text" value="True" /> | <input type="text" value="False" />

__Razor V2 & V3-beta2 Output__
True | False | <input type="text" value="value" /> | <input type="text" />
In above V2 & V3-beta2 output we can see that it is rendering __value="value" for bool True, while for bool False it is not rendering value attribute at all__ Ideally it should be value="True" and value="False" respectively.
↧

Commented Feature: HttpHeaders collections should benefit from IEnumerable covariance [1127]

July 23, 2013, 6:37 am
$
0
0
Every HttpHeaders collections access from HttpRequestHeaders, HttpResponseHeaders, HttpContentHeaders that takes one of these type parameter:
MediaTypeWithQualityHeaderValue , NameValueWithParametersHeaderValue, TransferCodingWithQualityHeaderValue
should use their less specialized type parameter (without With_X_ in the type name) to benefit from IEnumerable<T> covariance. These collections construction or update should integrate default settings or type casting for Quality or Parameter but their concrete type should stay the more specialized one.
Comments: Do you want I support this issue in one issue tracking system? which one?
↧
Viewing all 7215 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>