Releases: stifskere/MemwLib
Middleware structure
Description
This release features changes in how the middleware is declared, the class UsesMiddlewareAttribute
no longer exists, so the whole "Declare method and use it as middleware" can't be done anymore. To create a middleware, you now must create a class that extends MiddlewareAttribute
. This enables you to add custom parameters to your middleware class.
class PrintBeforeRunMiddleware(string message) : MiddlewareAttribute
{
public override IResponsible Handler(RequestEntity request)
{
Console.WriteLine(message);
return Middleware.Next;
}
}
This is a middleware declaration, now to call the next middleware you return a Middleware.Next
property access, which internally is a new Middleware()
but semantically looks better, now you can use that middleware in your routes.
[RouteGroup("/example")]
public static class ExampleGroup
{
[PrintBeforeRunMiddleware("hello")]
[Route(RequestMethodType.Get, "/route")]
public static ResponseEntity ExampleRoute(RequestEntity request)
{
return new ResponseEntity(ResponseCodes.Ok);
}
}
Now this route prints "hello" every time it is called.
Changes
As explained before, UsesMiddlewareAttribute
no longer exists, this way enabling the use of parameters in middlewares.
+ [CustomMiddleware(...params)]
- [UsesMiddleware(typeof(Type), nameof(Type.Method))]
The route declaring attribute changed its name to RouteAttribute
. This being made to avoid confusion on what is a GroupMemberAttribute
.
+ [Route(RequestMethodType.Get, "/route")]
- [GroupMember(RequestMethodType.Get, "/route")]
The way you return from middlewares slightly changed now, you need to return a Middleware.Next
instead of a new NextMiddleware()
this being a simple semantic change, you can access the same methods and properties as before, the API didn't change, only its name and way of instantiation.
+ return Middleware.Next;
- return new NextMiddleware();
v3.1.0
Description
This release comes with cookies!
Features
There is now a cookies extension class, you can use in any IResponsible
implementation.
new ResponseEntity(ResponseCodes.Ok)
.WithCookie(new Cookie{ Name = "", Value = "" /*...*/ });
Headers are now a multiple value to one key map, meaning that you now may add a single cookie using the Add(string, string)
method, otherwise, if using the indexer, you will need to pass an array.
- response.Headers["Name"] = "value";
+ response.Headers["Name"] = ["value"];
To add a single value to a key, simply use
response.Headers.Add("Name", "value");
Since all the collections implement IEnumerable
, LINQ is available, so you may remove a single value from a key using it, mind that internally multiple value to one key maps are handled as a List<KeyValuePair<TKey, TValue>>
.
Using the collection Remove(string)
will remove all the values related to that key, so an example of removal using LINQ would be
response.Headers.RemoveAll(pair => pair.Value == "some value");
The WithoutCookie(this IResponsible, string)
method only adds a Set-Cookie
header with an anterior date as per this, so you might want to parse inside the RemoveAll
method and check whether it has a value or a specified property.
response.Headers.RemoveAll(pair => pair.Key == "Set-Cookie" && Cookie.Parse(pair.value).Name == "CookieName");
Even tho, handling the cookie addition conditionally is always preferred.
Fixes
Parsers and strings are now file format agnostic, meaning that not mattering if the new line format is CL
or CLRF
the new lines are handled based on the System.Environment.NewLine
constant property.
Body fixes
Description
This release is mostly about fixes, it fixes the body sending, as before it converted the Stream
to a String
and then to a Byte[]
this way breaking any custom binary format, but now it conserves the format as it's sent by the user.
v3.0.0
Response interceptors
This release fixes 2 things.
/
routes not being recognized, these threw 404, not anymore.- Flagged enum request types didn't match all the flags.
It also comes with a new feature
- Added response interceptors which let you intercept a response like 404, 500 and send a custom response instead.
Second Release
This release contains what the first release did, but actually working, I also added data managing classes and changed how HTTP parsing worked to an actual version that has sense.
Higher bit color types
Higher bit color types
What this release features is just <Rgb48>
and <Rgb64>
color types, which are not related to 24-bit and 32-bit color types.
To read more about it, check the documentation in the README
First release
First release
This release features one of the ideas I had for this library, which is an HTTP server and colors for future implementations.
To read the documentation, go read the README.