Instead of having a custom, private copy of StyleCop build logic (WebStack.StyleCop.targets), create a standard StyleCop targets NuGet package (that could be shared by others projects such as EF). Also see if the StyleCop owners would consider taking ownership of this package.
↧
Edited Task: MQ: Move StyleCop build logic out into a NuGet package [1170]
↧
Edited Task: MQ: Move xUnit build logic out into a NuGet package [1171]
Instead of having a custom, private copy of xUnit build system (test runner) logic (WebStack.xunit.targets), create a standard xUnit targets NuGet package (and share it with other projects such as EF). Also see if the xUnit owners would consider taking ownership of this package.
Note that the EF team is interested in this work as well and might be done in collaboration with them.
Note that the EF team is interested in this work as well and might be done in collaboration with them.
↧
↧
Created Task: MQ: Update to latest NuGet.targets [1172]
NuGet package restore requires having a checked-in copy of NuGet.targets. We haven't updated ours in a while.
Also, we should examine how the EF team handles interation between NuGet.targets and Runtime.msbuild and see if they have an approach we should follow to keep custom code out of NuGet.targets as much as possible (to make further updates like this one easier).
Also, we should examine how the EF team handles interation between NuGet.targets and Runtime.msbuild and see if they have an approach we should follow to keep custom code out of NuGet.targets as much as possible (to make further updates like this one easier).
↧
Created Unassigned: In OWIN environment, for some cases 404 response does not have error message in the body [1173]
__Scenario__:
User has a Katana based selfhosted application and is making a request to a non-existing controller
__Issue__:
Response body does not have the detailed error message that Web API usually gives for these kind of scenarios.
__Reason__:
We introduced something called "Soft" 404 to handle scenarios where Web API shouldn't respond directly to the client, but instead invoke any middleware registered 'after' Web API.
In the logic that we currently have, we are eagerly discarding the response body(which would have had the error message that i am expecting) if its a "Soft" 404 and then checking for presence of any registered middleware and invoking it. But if there was no middleware registered, then we should ideally be returing back the correct response, which is including the response body.
__Expected__: {"Message":"No HTTP resource was found that matches the request URI 'http://localhost:14459/api/doesnotexist'.","MessageDetail":"No type was found that matches the controller named 'doesnotexist'."}
__Actual__: No body
__Attached__ a katana selfhost repro.
User has a Katana based selfhosted application and is making a request to a non-existing controller
__Issue__:
Response body does not have the detailed error message that Web API usually gives for these kind of scenarios.
__Reason__:
We introduced something called "Soft" 404 to handle scenarios where Web API shouldn't respond directly to the client, but instead invoke any middleware registered 'after' Web API.
In the logic that we currently have, we are eagerly discarding the response body(which would have had the error message that i am expecting) if its a "Soft" 404 and then checking for presence of any registered middleware and invoking it. But if there was no middleware registered, then we should ideally be returing back the correct response, which is including the response body.
__Expected__: {"Message":"No HTTP resource was found that matches the request URI 'http://localhost:14459/api/doesnotexist'.","MessageDetail":"No type was found that matches the controller named 'doesnotexist'."}
__Actual__: No body
__Attached__ a katana selfhost repro.
↧
Edited Unassigned: In OWIN environment, for some cases 404 response does not have error message in the body [1173]
__Scenario__:
User has a Katana based selfhosted application and is making a request to a non-existing controller
__Issue__:
Response body does not have the detailed error message that Web API usually gives for these kind of scenarios.
__Reason__:
We introduced something called "Soft" 404 to handle scenarios where Web API shouldn't respond directly to the client, but instead invoke any middleware registered 'after' Web API.
In the logic that we currently have, we are eagerly discarding the response body(which would have had the error message that i am expecting) if its a "Soft" 404 and then checking for presence of any registered middleware and invoking it. But if there was no middleware registered, then we should ideally be returing back the correct response, which is including the response body.
__Expected__: {"Message":"No HTTP resource was found that matches the request URI 'http://localhost:14459/api/doesnotexist'.","MessageDetail":"No type was found that matches the controller named 'doesnotexist'."}
__Actual__: No body
__Attached__ a katana selfhost repro.
__HttpMessageHandlerAdapter__ source code(Notice the condition _if (IsSoftNotFound(request, response))_):
```
HttpResponseMessage response = null;
bool callNext = false;
try
{
response = await _messageInvoker.SendAsync(request, owinRequest.CallCancelled);
// Handle null responses
if (response == null)
{
throw Error.InvalidOperation(OwinResources.SendAsync_ReturnedNull);
}
// Handle soft 404s where no route matched - call the next component
if (IsSoftNotFound(request, response))
{
callNext = true;
}
else
{
if (response.Content != null && _bufferPolicySelector.UseBufferedOutputStream(response))
{
response = await BufferResponseBodyAsync(request, response);
}
FixUpContentLengthHeaders(response);
await SendResponseMessageAsync(response, owinResponse);
}
}
finally
{
// Note that the HttpRequestMessage is explicitly NOT disposed. Disposing it would close the input stream
// and prevent cascaded components from accessing it. The server MUST handle any necessary cleanup upon
// request completion.
request.DisposeRequestResources();
if (response != null)
{
response.Dispose();
}
}
// Call the next component if no route matched
if (callNext && Next != null)
{
await Next.Invoke(context);
}
```
User has a Katana based selfhosted application and is making a request to a non-existing controller
__Issue__:
Response body does not have the detailed error message that Web API usually gives for these kind of scenarios.
__Reason__:
We introduced something called "Soft" 404 to handle scenarios where Web API shouldn't respond directly to the client, but instead invoke any middleware registered 'after' Web API.
In the logic that we currently have, we are eagerly discarding the response body(which would have had the error message that i am expecting) if its a "Soft" 404 and then checking for presence of any registered middleware and invoking it. But if there was no middleware registered, then we should ideally be returing back the correct response, which is including the response body.
__Expected__: {"Message":"No HTTP resource was found that matches the request URI 'http://localhost:14459/api/doesnotexist'.","MessageDetail":"No type was found that matches the controller named 'doesnotexist'."}
__Actual__: No body
__Attached__ a katana selfhost repro.
__HttpMessageHandlerAdapter__ source code(Notice the condition _if (IsSoftNotFound(request, response))_):
```
HttpResponseMessage response = null;
bool callNext = false;
try
{
response = await _messageInvoker.SendAsync(request, owinRequest.CallCancelled);
// Handle null responses
if (response == null)
{
throw Error.InvalidOperation(OwinResources.SendAsync_ReturnedNull);
}
// Handle soft 404s where no route matched - call the next component
if (IsSoftNotFound(request, response))
{
callNext = true;
}
else
{
if (response.Content != null && _bufferPolicySelector.UseBufferedOutputStream(response))
{
response = await BufferResponseBodyAsync(request, response);
}
FixUpContentLengthHeaders(response);
await SendResponseMessageAsync(response, owinResponse);
}
}
finally
{
// Note that the HttpRequestMessage is explicitly NOT disposed. Disposing it would close the input stream
// and prevent cascaded components from accessing it. The server MUST handle any necessary cleanup upon
// request completion.
request.DisposeRequestResources();
if (response != null)
{
response.Dispose();
}
}
// Call the next component if no route matched
if (callNext && Next != null)
{
await Next.Invoke(context);
}
```
↧
↧
Edited Unassigned: In OWIN environment, for some cases 404 response does not have error message in the body [1173]
__Scenario__:
User has a Katana based selfhosted application and is making a request to a non-existing controller
__Issue__:
Response body does not have the detailed error message that Web API usually gives for these kind of scenarios. This would also effect any response headers that might have been added to the response.
__Reason__:
We introduced something called "Soft" 404 to handle scenarios where Web API shouldn't respond directly to the client, but instead invoke any middleware registered 'after' Web API.
In the logic that we currently have, we are eagerly discarding the response body(which would have had the error message that i am expecting) if its a "Soft" 404 and then checking for presence of any registered middleware and invoking it. But if there was no middleware registered, then we should ideally be returing back the correct response, which is including the response body.
__Expected__: {"Message":"No HTTP resource was found that matches the request URI 'http://localhost:14459/api/doesnotexist'.","MessageDetail":"No type was found that matches the controller named 'doesnotexist'."}
__Actual__: No body
__Attached__ a katana selfhost repro.
__HttpMessageHandlerAdapter__ source code(Notice the condition _if (IsSoftNotFound(request, response))_):
```
HttpResponseMessage response = null;
bool callNext = false;
try
{
response = await _messageInvoker.SendAsync(request, owinRequest.CallCancelled);
// Handle null responses
if (response == null)
{
throw Error.InvalidOperation(OwinResources.SendAsync_ReturnedNull);
}
// Handle soft 404s where no route matched - call the next component
if (IsSoftNotFound(request, response))
{
callNext = true;
}
else
{
if (response.Content != null && _bufferPolicySelector.UseBufferedOutputStream(response))
{
response = await BufferResponseBodyAsync(request, response);
}
FixUpContentLengthHeaders(response);
await SendResponseMessageAsync(response, owinResponse);
}
}
finally
{
// Note that the HttpRequestMessage is explicitly NOT disposed. Disposing it would close the input stream
// and prevent cascaded components from accessing it. The server MUST handle any necessary cleanup upon
// request completion.
request.DisposeRequestResources();
if (response != null)
{
response.Dispose();
}
}
// Call the next component if no route matched
if (callNext && Next != null)
{
await Next.Invoke(context);
}
```
User has a Katana based selfhosted application and is making a request to a non-existing controller
__Issue__:
Response body does not have the detailed error message that Web API usually gives for these kind of scenarios. This would also effect any response headers that might have been added to the response.
__Reason__:
We introduced something called "Soft" 404 to handle scenarios where Web API shouldn't respond directly to the client, but instead invoke any middleware registered 'after' Web API.
In the logic that we currently have, we are eagerly discarding the response body(which would have had the error message that i am expecting) if its a "Soft" 404 and then checking for presence of any registered middleware and invoking it. But if there was no middleware registered, then we should ideally be returing back the correct response, which is including the response body.
__Expected__: {"Message":"No HTTP resource was found that matches the request URI 'http://localhost:14459/api/doesnotexist'.","MessageDetail":"No type was found that matches the controller named 'doesnotexist'."}
__Actual__: No body
__Attached__ a katana selfhost repro.
__HttpMessageHandlerAdapter__ source code(Notice the condition _if (IsSoftNotFound(request, response))_):
```
HttpResponseMessage response = null;
bool callNext = false;
try
{
response = await _messageInvoker.SendAsync(request, owinRequest.CallCancelled);
// Handle null responses
if (response == null)
{
throw Error.InvalidOperation(OwinResources.SendAsync_ReturnedNull);
}
// Handle soft 404s where no route matched - call the next component
if (IsSoftNotFound(request, response))
{
callNext = true;
}
else
{
if (response.Content != null && _bufferPolicySelector.UseBufferedOutputStream(response))
{
response = await BufferResponseBodyAsync(request, response);
}
FixUpContentLengthHeaders(response);
await SendResponseMessageAsync(response, owinResponse);
}
}
finally
{
// Note that the HttpRequestMessage is explicitly NOT disposed. Disposing it would close the input stream
// and prevent cascaded components from accessing it. The server MUST handle any necessary cleanup upon
// request completion.
request.DisposeRequestResources();
if (response != null)
{
response.Dispose();
}
}
// Call the next component if no route matched
if (callNext && Next != null)
{
await Next.Invoke(context);
}
```
↧
Created Unassigned: Set metadata url in ODataMediaTypeFormatter for ODataErrors [1174]
The current code for ODataMediaTypeFormatter contains the following code fragment:
```
// The MetadataDocumentUri is never required for errors. Additionally, it sometimes won't be available
// for errors, such as when routing itself fails. In that case, the route data property is not
// available on the request, and due to a bug with HttpRoute.GetVirtualPath (bug #669) we won't be able
// to generate a metadata link.
if (serializer.ODataPayloadKind != ODataPayloadKind.Error)
{
string metadataLink = urlHelper.ODataLink(new MetadataPathSegment());
if (metadataLink == null)
{
throw new SerializationException(SRResources.UnableToDetermineMetadataUrl);
}
string selectClause = GetSelectClause(Request);
writerSettings.SetMetadataDocumentUri(new Uri(metadataLink), selectClause);
}
```
The if clause is no longer necessary as issue 669 has already been fixed, and it will cause a failure when we update to ODataLib 5.6 so this change has to be made when we upgrade to ODataLib 5.6.
```
// The MetadataDocumentUri is never required for errors. Additionally, it sometimes won't be available
// for errors, such as when routing itself fails. In that case, the route data property is not
// available on the request, and due to a bug with HttpRoute.GetVirtualPath (bug #669) we won't be able
// to generate a metadata link.
if (serializer.ODataPayloadKind != ODataPayloadKind.Error)
{
string metadataLink = urlHelper.ODataLink(new MetadataPathSegment());
if (metadataLink == null)
{
throw new SerializationException(SRResources.UnableToDetermineMetadataUrl);
}
string selectClause = GetSelectClause(Request);
writerSettings.SetMetadataDocumentUri(new Uri(metadataLink), selectClause);
}
```
The if clause is no longer necessary as issue 669 has already been fixed, and it will cause a failure when we update to ODataLib 5.6 so this change has to be made when we upgrade to ODataLib 5.6.
↧
Created Unassigned: [OData] Deserialization should fail when a required field is not present on the Payload [1175]
Having an entity like the following:
```
public class UntypedCustomer
{
public int Id { get; set; }
public string Name { get; set; }
public virtual IList<UntypedOrder> Orders { get; set; }
public virtual IList<UntypedAddress> Addresses { get; set; }
public virtual IList<int> FavoriteNumbers { get; set; }
}
```
and a service that defines an entity set of entities with a required property:
```
ODataModelBuilder builder = new ODataConventionModelBuilder();
var customers = builder.EntitySet<UntypedCustomer>("UntypedCustomers");
customers.EntityType.Property(c => c.Name).IsRequired();
```
when the user sends a payload without the required field:
```
{
"Id": 10,
"Orders": [],
"Addresses": [],
"FavoriteNumbers": []
}
```
the deserialization should fail instead of assigning the default value to the field.
```
public class UntypedCustomer
{
public int Id { get; set; }
public string Name { get; set; }
public virtual IList<UntypedOrder> Orders { get; set; }
public virtual IList<UntypedAddress> Addresses { get; set; }
public virtual IList<int> FavoriteNumbers { get; set; }
}
```
and a service that defines an entity set of entities with a required property:
```
ODataModelBuilder builder = new ODataConventionModelBuilder();
var customers = builder.EntitySet<UntypedCustomer>("UntypedCustomers");
customers.EntityType.Property(c => c.Name).IsRequired();
```
when the user sends a payload without the required field:
```
{
"Id": 10,
"Orders": [],
"Addresses": [],
"FavoriteNumbers": []
}
```
the deserialization should fail instead of assigning the default value to the field.
↧
Created Unassigned: HttpActionExecutedContext.Response setter throws exception [1176]
Simple object initializer setting the response property
```
var context = new HttpActionExecutedContext
{
Response = new Http.HttpResponseMessage()
};
```
throws an exception:
```
System.NullReferenceException: Object reference not set to an instance of an object.
at System.Web.Http.Filters.HttpActionExecutedContext.set_Response(HttpResponseMessage value)
```
NuGet package Microsoft.Net.Http ver. __2.2.13__
```
var context = new HttpActionExecutedContext
{
Response = new Http.HttpResponseMessage()
};
```
throws an exception:
```
System.NullReferenceException: Object reference not set to an instance of an object.
at System.Web.Http.Filters.HttpActionExecutedContext.set_Response(HttpResponseMessage value)
```
NuGet package Microsoft.Net.Http ver. __2.2.13__
↧
↧
Edited Unassigned: [AttributeRouting]Route not being added to route collection [1005]
__Note__: This behavior exists even in MVC attribute routing too. I haven't filed a new bug for it, but would like to use this bug.
In the following scenario, the Get() action on ReproController, which is decorated with an attribute route is _not_ being added to the route collection.
On the other hand, the Get() action on the WorkingConroller is added to the route collection as expected.
Expected: Get() action on ReproController should be part of route collection
Actual: Not added to route collection.
```
public class ReproController : ApiController
{
//NOTE: NOT added to route collection
[HttpGet(RouteName="GetAllValues")]
public string Get()
{
return "Repro.GetAllValues";
}
}
public class WorkingController : ApiController
{
//NOTE: ADDED to route collection. Notice the empty route template
[HttpGet("", RouteName = "GetAllValues2")]
public string Get()
{
return "Working.GetAllValues2";
}
}
```
In the following scenario, the Get() action on ReproController, which is decorated with an attribute route is _not_ being added to the route collection.
On the other hand, the Get() action on the WorkingConroller is added to the route collection as expected.
Expected: Get() action on ReproController should be part of route collection
Actual: Not added to route collection.
```
public class ReproController : ApiController
{
//NOTE: NOT added to route collection
[HttpGet(RouteName="GetAllValues")]
public string Get()
{
return "Repro.GetAllValues";
}
}
public class WorkingController : ApiController
{
//NOTE: ADDED to route collection. Notice the empty route template
[HttpGet("", RouteName = "GetAllValues2")]
public string Get()
{
return "Working.GetAllValues2";
}
}
```
↧
Edited Issue: Depend upon abstractions instead of concrete implementations for instancing Edm* types [1178]
For example, EdmEntityObjectCollections constructor takes a IList<EdmObject> instead of a List<IEdmObject>. This limit the ability for third parties to provide their own untyped implementation.
Review these problems on the untyped api and modify the API to depend on the abstractions.
Review these problems on the untyped api and modify the API to depend on the abstractions.
↧
Commented Issue: Expose queryable mode option in ODataConvetionModelBuilder [804]
This is useful for unit testing following actions:
IQueryable<string> Get(ODataQueryOptions<Todo> options)
Users have to build options by themselves and in that case, they need a queryable mode model. Otherwise, the model builder won't work for some cases like no-ID entities.
Comments: [Fixed](https://aspnetwebstack.codeplex.com/SourceControl/changeset/ec3aee80b914953a9a5bfd844420f2da39ca8860).
IQueryable<string> Get(ODataQueryOptions<Todo> options)
Users have to build options by themselves and in that case, they need a queryable mode model. Otherwise, the model builder won't work for some cases like no-ID entities.
Comments: [Fixed](https://aspnetwebstack.codeplex.com/SourceControl/changeset/ec3aee80b914953a9a5bfd844420f2da39ca8860).
↧
Edited Issue: Expose queryable mode option in ODataConvetionModelBuilder [804]
This is useful for unit testing following actions:
IQueryable<string> Get(ODataQueryOptions<Todo> options)
Users have to build options by themselves and in that case, they need a queryable mode model. Otherwise, the model builder won't work for some cases like no-ID entities.
IQueryable<string> Get(ODataQueryOptions<Todo> options)
Users have to build options by themselves and in that case, they need a queryable mode model. Otherwise, the model builder won't work for some cases like no-ID entities.
↧
↧
Edited Issue: Use the SerializerProvider in the parameter instead of RawValueSerializerProvider [970]
In the ODataMediaTypeFormatters.cs file, in the Create method
CreateRawValue(new RawValueSerializerProvider(), deserializerProvider) uses it's own SerializerProvider instead of the one provided by the the parameter.
Refactor the code so that the serializer provided in the parameter is used.
CreateRawValue(new RawValueSerializerProvider(), deserializerProvider) uses it's own SerializerProvider instead of the one provided by the the parameter.
Refactor the code so that the serializer provided in the parameter is used.
↧
Commented Issue: Use the SerializerProvider in the parameter instead of RawValueSerializerProvider [970]
In the ODataMediaTypeFormatters.cs file, in the Create method
CreateRawValue(new RawValueSerializerProvider(), deserializerProvider) uses it's own SerializerProvider instead of the one provided by the the parameter.
Refactor the code so that the serializer provided in the parameter is used.
Comments: [Fixed](https://aspnetwebstack.codeplex.com/SourceControl/changeset/241005b9351c9f7860f5da5b994c5603b9ade19a).
CreateRawValue(new RawValueSerializerProvider(), deserializerProvider) uses it's own SerializerProvider instead of the one provided by the the parameter.
Refactor the code so that the serializer provided in the parameter is used.
Comments: [Fixed](https://aspnetwebstack.codeplex.com/SourceControl/changeset/241005b9351c9f7860f5da5b994c5603b9ade19a).
↧
Created Unassigned: Low performance while serializing large OData feeds [1183]
```
public class ProductsController : ODataController
{
//[Queryable(PageSize = 10)]
public IQueryable<Product> Get()
{
return Product.Resources.AsQueryable();
}
}
public class Product
{
public int ID { get; set; }
public string Name { get; set; }
public decimal Price { get; set; }
public string Category { get; set; }
public virtual List<Supplier> Suppliers { get; set; }
public Product()
{
this.Suppliers = new List<Supplier>();
}
static private List<Product> resources;
static public List<Product> Resources
{
get
{
if (resources == null)
{
resources = new List<Product>();
for (int i = 0; i < 3000; i++)
{
resources.Add(new Product { ID = i, Name = "product" + i, Price = 45.0M, Category = "food" });
}
}
return resources;
}
}
}
public class Supplier
{
public string Name { get; set; }
public string EmailId { get; set; }
public List<Product> Products { get; private set; }
public Supplier()
{
this.Products = new List<Product>();
}
static public List<Supplier> Resources = new List<Supplier>()
{
new Supplier() { Name = "Contoso", EmailId = "president@contoso.com" },
new Supplier() { Name = "Fabrikam", EmailId = "president@fabrikam.com" },
};
}
```
Serializing the Products feed without page size has low performance of around 40 requests/sec.
public class ProductsController : ODataController
{
//[Queryable(PageSize = 10)]
public IQueryable<Product> Get()
{
return Product.Resources.AsQueryable();
}
}
public class Product
{
public int ID { get; set; }
public string Name { get; set; }
public decimal Price { get; set; }
public string Category { get; set; }
public virtual List<Supplier> Suppliers { get; set; }
public Product()
{
this.Suppliers = new List<Supplier>();
}
static private List<Product> resources;
static public List<Product> Resources
{
get
{
if (resources == null)
{
resources = new List<Product>();
for (int i = 0; i < 3000; i++)
{
resources.Add(new Product { ID = i, Name = "product" + i, Price = 45.0M, Category = "food" });
}
}
return resources;
}
}
}
public class Supplier
{
public string Name { get; set; }
public string EmailId { get; set; }
public List<Product> Products { get; private set; }
public Supplier()
{
this.Products = new List<Product>();
}
static public List<Supplier> Resources = new List<Supplier>()
{
new Supplier() { Name = "Contoso", EmailId = "president@contoso.com" },
new Supplier() { Name = "Fabrikam", EmailId = "president@fabrikam.com" },
};
}
```
Serializing the Products feed without page size has low performance of around 40 requests/sec.
↧
Commented Issue: Methods with matrix parameters are not shown in help page [1122]
Our team decided to use standard query parameters in URIs only for sorting and paging and other non filtering actions on resources. For filtering we want to use matrix parameters.
Since it is not guaranteed that query parameters are being cached, matrix parameters should be used where applicable. But when using matrix parameters the help page wont show these requests.
Example:
```
/// <summary>
/// Get customers
/// </summary>
/// <param name="name">Name of the customer.</param>
/// <param name="surname">Surname of the customer.</param>
/// <returns>Returns a list of customers.</returns>
[HttpGet("api/customers;name={name};surname={surname}")]
public IEnumerable<Customer> GetByFilter(string name, string surname)
{
...
}
```
Instead of:
```
/// <summary>
/// Get customers
/// </summary>
/// <param name="name">Name of the customer.</param>
/// <param name="surname">Surname of the customer.</param>
/// <returns>Returns a list of customers.</returns>
[HttpGet("api/customers?name={name?}&surname={surname?}")]
public IEnumerable<Customer> GetByFilter(string name, string surname)
{
...
}
```
Kind regards,
Andy
Comments: I can't repro the issue. The matrix parameters do show up on the help page (See attached sample project). Please provide us with a repro so that we can continue the investigation. Thanks, Yao
Since it is not guaranteed that query parameters are being cached, matrix parameters should be used where applicable. But when using matrix parameters the help page wont show these requests.
Example:
```
/// <summary>
/// Get customers
/// </summary>
/// <param name="name">Name of the customer.</param>
/// <param name="surname">Surname of the customer.</param>
/// <returns>Returns a list of customers.</returns>
[HttpGet("api/customers;name={name};surname={surname}")]
public IEnumerable<Customer> GetByFilter(string name, string surname)
{
...
}
```
Instead of:
```
/// <summary>
/// Get customers
/// </summary>
/// <param name="name">Name of the customer.</param>
/// <param name="surname">Surname of the customer.</param>
/// <returns>Returns a list of customers.</returns>
[HttpGet("api/customers?name={name?}&surname={surname?}")]
public IEnumerable<Customer> GetByFilter(string name, string surname)
{
...
}
```
Kind regards,
Andy
Comments: I can't repro the issue. The matrix parameters do show up on the help page (See attached sample project). Please provide us with a repro so that we can continue the investigation. Thanks, Yao
↧
↧
Edited Feature: Add overloads taking a CancellationToken parameter [983]
Currently some of TAP-based methods in the aspnetwebstack libraries does not have overloads with _CancellationToken_ parameter. For instance following classes:
_System.Net.Http_: HttpContent and successors.
```
HttpContent: ReadAsStringAsync, ReadAsByteArrayAsync, ReadAsStreamAsync, etc.
```
_System.Net.Http.Formatting_: HttpContent extensions.
```
HttpContentMessageExtensions: ReadAsHttpRequestMessageAsync
HttpContentMultipartExtensions: ReadAsMultipartAsync
HttpContentFormDataExtensions: ReadAsFormDataAsync
HttpContentMessageExtensions: ReadAsHttpRequestMessageAsync
MultipartStreamProvider: ExecutePostProcessingAsync
```
_System.Net.Http.Formatting_: MediaTypeFormatter and successors.
```
MediaTypeFormatter: ReadFromStreamAsync, WriteToStreamAsync
BufferedMediaTypeFormatter
FormUrlEncodedMediaTypeFormatter
JsonMediaTypeFormatter
XmlMediaTypeFormatter
```
_System.Web.Http_: Model binder which breaks cancellable pipeline.
```
FormatterParameterBinding: ReadContentAsync
```
Methods of above classes potentially may be executed for a long time period. In addition if we're trying to create custom _MediaTypeFormatter_ we unable to cancel _ReadFromStreamAsync_ and _WriteToStreamAsync_ methods.
I suppose that it will be great if such methods will contain an overloads with a _CancellationToken_ parameter, which should be properly integrated into Web API message processing pipeline.
Code sample how it can be refactored: https://aspnetwebstack.codeplex.com/SourceControl/network/forks/dtretyakov/CancellationToken/contribution/4472
P.S. Discussions looks dead - no answers for over 2 weeks: http://aspnetwebstack.codeplex.com/discussions/438601
_System.Net.Http_: HttpContent and successors.
```
HttpContent: ReadAsStringAsync, ReadAsByteArrayAsync, ReadAsStreamAsync, etc.
```
_System.Net.Http.Formatting_: HttpContent extensions.
```
HttpContentMessageExtensions: ReadAsHttpRequestMessageAsync
HttpContentMultipartExtensions: ReadAsMultipartAsync
HttpContentFormDataExtensions: ReadAsFormDataAsync
HttpContentMessageExtensions: ReadAsHttpRequestMessageAsync
MultipartStreamProvider: ExecutePostProcessingAsync
```
_System.Net.Http.Formatting_: MediaTypeFormatter and successors.
```
MediaTypeFormatter: ReadFromStreamAsync, WriteToStreamAsync
BufferedMediaTypeFormatter
FormUrlEncodedMediaTypeFormatter
JsonMediaTypeFormatter
XmlMediaTypeFormatter
```
_System.Web.Http_: Model binder which breaks cancellable pipeline.
```
FormatterParameterBinding: ReadContentAsync
```
Methods of above classes potentially may be executed for a long time period. In addition if we're trying to create custom _MediaTypeFormatter_ we unable to cancel _ReadFromStreamAsync_ and _WriteToStreamAsync_ methods.
I suppose that it will be great if such methods will contain an overloads with a _CancellationToken_ parameter, which should be properly integrated into Web API message processing pipeline.
Code sample how it can be refactored: https://aspnetwebstack.codeplex.com/SourceControl/network/forks/dtretyakov/CancellationToken/contribution/4472
P.S. Discussions looks dead - no answers for over 2 weeks: http://aspnetwebstack.codeplex.com/discussions/438601
↧
Edited Issue: Parameter binding information not being traced when attribute routing is used [1131]
__Scenario__: User would like to trace the incoming request to diagnose an issue.
__Issue__: When attribute routing is used, the traces are missing the parameter binding information.
__Possible Reason__: When "config.MapHttpAttributeRoutes()" is called, we store the action descriptors as data tokens in each of these generated routes. I am calling "config.EnableSystemDiagnosticTracing" after the above call, but I have tried calling it before and it didn't make any difference. I wasn't able to debug to the root cause, but I am guessing the problem could be timing of the wrapping of action binding tracers.
__Note__:
- Attached a standalone katana self host.
- Attached a snapshot having comparison between traces when AR is used and when not used.
__Issue__: When attribute routing is used, the traces are missing the parameter binding information.
__Possible Reason__: When "config.MapHttpAttributeRoutes()" is called, we store the action descriptors as data tokens in each of these generated routes. I am calling "config.EnableSystemDiagnosticTracing" after the above call, but I have tried calling it before and it didn't make any difference. I wasn't able to debug to the root cause, but I am guessing the problem could be timing of the wrapping of action binding tracers.
__Note__:
- Attached a standalone katana self host.
- Attached a snapshot having comparison between traces when AR is used and when not used.
↧
Edited Issue: Web API: Improve resolution of ApiController types [1075]
If an assembly A contains ApiControllers and it references another assembly B that does not contain ApiControllers and this assembly B is not found (because it is not installed for example) controller type resolution does not find the ApiControllers in assembly A.
In this case only a 404 status code is returned together with a HttpError message indicating that no matching controller for the specified route could be found. There is no indication __why__ this controller (that actually exists) has not been found.
For a developer who experiences this behaviour (lots of or even all routes return 404) this error is very hard to detect and to analyze. An improvement of either controller type resolution (prefered in my opinion) or at least error reporting or tracing would be very welcome.
Details about this problem are in this Stackoverflow question and its answers:
http://stackoverflow.com/questions/16812995/all-requests-to-asp-net-web-api-return-404-error
I'd like to mention that type resolution for MVC controllers does not suffer from this problem. MVC controllers in assembly A are found, even when assembly B is missing. It would be good in my opinion if controller type resolution in Web API would behave the same way.
In this case only a 404 status code is returned together with a HttpError message indicating that no matching controller for the specified route could be found. There is no indication __why__ this controller (that actually exists) has not been found.
For a developer who experiences this behaviour (lots of or even all routes return 404) this error is very hard to detect and to analyze. An improvement of either controller type resolution (prefered in my opinion) or at least error reporting or tracing would be very welcome.
Details about this problem are in this Stackoverflow question and its answers:
http://stackoverflow.com/questions/16812995/all-requests-to-asp-net-web-api-return-404-error
I'd like to mention that type resolution for MVC controllers does not suffer from this problem. MVC controllers in assembly A are found, even when assembly B is missing. It would be good in my opinion if controller type resolution in Web API would behave the same way.
↧