Cannot post event in .Net Core when SEQ base url has relative path

[calvin998]

It seems this issue exists in .Net Core environment only. When the SEQ base address doesn't have a relative path (e.g. http://myseqserver.com) it works fine. Once the configuration is changed to http://myseqserver.com/seq, the local debugging message will display

Received failed result NotFound when posting events to Seq

Further investigation showed that when HttpClient.BaseAddress is set this way, the relative path will be ignored in PostAsync(). I checked the Request data url in the returned data of PostAsync() and found that PostAsync() always stripes out the relative path and merges the Host address with PostAsync() target. So:

_httpClient.BaseAddress = new Uri(SeqApi.NormalizeServerBaseAddress("http://myseqserver.com/seq"));
var result = await _httpClient.PostAsync("api/events/raw", content).ConfigureAwait(false);

ends up only posting to "http://myseqserver.com/api/events/raw".

To get around this strange behavior, you have to parse the base address and set it the relative path explicitly:

_httpClient.BaseAddress = new Uri(new Uri("http://myseqserver.com/"), "seq/");

Also the relative path must end with slash or it will be ignored.

In my environment we have api gateway before the SEQ instance. Many services share the same DNS entry so we have to use relative path. Adding support for relative path in SEQ address will really helps.

Thanks!

[nblumhardt]

Thanks for the report!

I'm having some trouble reproducing this with Serilog.Sinks.Seq running on .NET Core 2.0 on Windows, against a Seq 4.2.1232 server.

Could you please let me know the versions, client, and server operating systems you're working with?

Cheers,
Nick

[calvin998]

Hi Nick,

This is the reference of my project

<PackageReference Include="Serilog" Version="2.7.1" />
<PackageReference Include="Serilog.AspNetCore" Version="2.1.1" />
<PackageReference Include="Serilog.Sinks.Seq" Version="4.0.0" />

I tried both Net Core 2.0 web api and console with same result. The server is 3.4.20 but I don't think it matters because the issue is at the client side. This is how I config the SeriLog

var logConfig = new LoggerConfiguration()
.Enrich.FromLogContext()
.Enrich.WithProperty("AppType", logSetting.AppType)
.Enrich.WithProperty("AppName", logSetting.AppName)
.Enrich.WithProperty("Team", logSetting.Team);
logConfig = logConfig.Enrich.With<LoggingHttpEnricher>();
logConfig.WriteTo.Seq(logSetting.seqServerUrl, compact: true);

I also have this to dump client error code on my console:

Serilog.Debugging.SelfLog.Enable(Console.Error);

When the above logSetting.seqServerUrl is http://somednc.com/seq, the error I got back is from this line in Seq sink - http status is 404. Once I changed my setting to IP:port (without relative path), it works fine. Exact same code and same SEQ server.

I used this code snippet to verify the HttpClient behavior:

var _httpClient = new HttpClient();
_httpClient.BaseAddress = new Uri("https://myserver.com/seq/");
var content = new StringContent("{ 'Events': [{ 'Timestamp': '2018-07-02T22:09:08.12345+10:00','Level': 'Warning', 'MessageTemplate': 'Testing from {Drive}', 'Properties': { 'Drive': 'oceans 12' }}]}", Encoding.UTF8, "application/json");
var result = _httpClient.PostAsync("api/events/raw", content).Result;

If you check the Request property of the result variable, you will see the actual request uri is "https://myserver.com/api/events/raw" - /seq/ is removed. But this line works:

_httpClient.BaseAddress = new Uri(new Uri("https://myserver.com/"), "seq/");

My .NET 4.x code works fine with relative path in the SEQ url. I guess that's because the HttpClient implementation of Net 4.x is different.

[nblumhardt]

Thanks for the follow-up. I'm still struggling to wrap my head around this or reproduce it (though I don't doubt something's going on there!)

Once I changed my setting to IP:port (without relative path), it works fine.

Do you have two Seq instances listening on the host? (If you omit the relative path, this will hit the root Seq instance.)

Could you please let me know what you see (it should be JSON) if you access the URL https://myserver.com/seq/api in a browser? Thanks!

[calvin998]

I only have one Seq instance. It's in an internal network. When I access it within the company LAN, I use http://10.10.10.10:5431 in my serilog configuration. Yes when I open the same address in a browser I saw the dashboard UI. However some of my web apps are hosted in DMZ and they can't log to this Seq server directly. We used an API gateway (Akana in this case). The dns https://myserver.com/seq was set up to point to http://10.10.10.10:5431. Only post action is allowed so when I type https://myserver.com/seq in a browser nothing comes up. The DNS record https://myserver.com is shared by many other services hosted behind this api gateway. For example https://myserver.com/user points to our user service web instance, https://myserver.com/product points to our product service web instance - it acts like a reverse proxy. When I use a Restful api testing tool (e.g. Postman) to manually post an event, either http://10.10.10.10:5431/api/events/raw or https://myserver.com/seq/api/events/raw works. However in my code, http://myserver.com/seq doesn't work (due to the HttpClient behavior I reported in my original post). Another work-around for Seq sink is to use HttpClient's SendAsync() method. So you don't set BaseAddress in your HttpClient (but save it as a plain string internally) then construct the full url when calling SendAsync(). This way you don't rely on PostAsync() to construct the final Url. Actually PostAsync() calls SendAsync() internally anyway: https://github.com/dotnet/corefx/blob/master/src/System.Net.Http/src/System/Net/Http/HttpClient.cs (line #312 to #318)/ Hope this clears your confusion. Thanks, Calvin

…

On Mon, Jul 2, 2018 at 4:33 PM Nicholas Blumhardt ***@***.***> wrote: Thanks for the follow-up. I'm still struggling to wrap my head around this or reproduce it (though I don't doubt something's going on there!) Once I changed my setting to IP:port (without relative path), it works fine. Do you have two Seq instances listening on the host? (If you omit the relative path, this will hit the root Seq instance.) Could you please let me know what you see (it should be JSON) if you access the URL https://myserver.com/seq/api in a browser? Thanks! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#108 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALf-DBcsSsoacxCzhygsdNb4pGATKKA2ks5uCq3UgaJpZM4U-my9> .

[nblumhardt]

Thanks for the detailed follow-up! 👍

I'm trying to figure out why this would occur in your case, but not elsewhere given the same library and URI setup... (It's important when making changes here for us to understand why they're necessary, both so that we can give adequate support, and so that we don't inadvertently break fixes with later changes). The best I can come up with is that there's a bugfix or breakage in a point version of the Uri class that's affecting us - it seems like UriKind.RelativeOrAbsolute and friends are a bit ........ crufty....

I think our best bet here is to fully-form the URI when the sink is configured, and use SendAsync() directly as you've suggested.