Skip to content

Releases: stifskere/MemwLib

Middleware structure

11 Apr 10:40
0c88496
Compare
Choose a tag to compare

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

05 Apr 14:50
Compare
Choose a tag to compare

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

30 Mar 10:42
43354aa
Compare
Choose a tag to compare

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

30 Mar 03:31
943a49a
Compare
Choose a tag to compare

What's Changed

  • Release stable version, explained in #3

Full Changelog: v2.1.0...v3.0.0

Response interceptors

16 Jan 14:52
42bc5dc
Compare
Choose a tag to compare

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

15 Jan 01:14
42bc5dc
Compare
Choose a tag to compare

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

25 Sep 02:32
bd1dae3
Compare
Choose a tag to compare

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

24 Sep 22:44
aba7970
Compare
Choose a tag to compare

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.