Endpoint details set in RequestSpecification aren't properly applied to endpoint

[bheemreddy181]

Currently, we support C# class objects for reading the Input API request , we might not need C# class objects all the time rather than creating a raw JSON for such cases can we support dictionary objects ?

[basdijkstra]

Json.NET has got you covered on that already. I've added an example to make this more clear, and I will add that to the docs as well:

rest-assured-net/RestAssured.Net.Tests/RequestBodySerializationTests.cs

Line 90 in fcde102

public void DictionaryCanBeSerializedToJson()

Does that answer your question? If so please close this issue, if not, please elaborate.

[basdijkstra]

Even better, it works with anonymous types, too, no need to even create a Dictionary:

rest-assured-net/RestAssured.Net.Tests/RequestBodySerializationTests.cs

Line 114 in 9d96a25

public void AnonymousObjectCanBeSerializedToJson()

[bheemreddy181]

Interesting, I was getting the below error with a dictionary

System.AggregateException : One or more errors occurred. (The 'file' scheme is not supported.)
  ----> System.NotSupportedException : The 'file' scheme is not supported.
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
   at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)
   at System.Threading.Tasks.Task`1.get_Result()
   at RestAssuredNet.RA.ExecutableRequest.Send(HttpMethod httpMethod, String endpoint)
   at RestAssuredNet.RA.ExecutableRequest.Post(String endpoint)
   at IntegrationTests.Tests.CreateLeadTests.CreateLeadTest() in /Users/bheemvennapureddy/SummitApi/IntegrationTests/Tests/CreateLeadTests.cs:line 33
--NotSupportedException
   at System.Net.Http.HttpClient.<SendAsync>g__Core|83_0(HttpRequestMessage request, HttpCompletionOption completionOption, CancellationTokenSource cts, Boolean disposeCts, CancellationTokenSource pendingRequestsCts, CancellationToken originalCancellationToken)
   at RestAssuredNet.RA.Internal.HttpRequestProcessor.Send(HttpRequestMessage request, CookieCollection cookieCollection)

[basdijkstra]

Can you add the test that you used?

[bheemreddy181]

Let me debug this a bit more and provide a detailed info on this.

[bheemreddy181]

I assume the endpoint is not getting set correctly from request Specification.

[basdijkstra]

Thanks.

Do you have a GitHub link somewhere where I can find the test? If not I’ll rebuild it myself but I might end up not having the exact same situation.

Can you see in your debug session what the complete endpoint is that RestAssured is trying to invoke?

And finally, did you run this against the public 1.0.0 version or did you package the library yourself?

[basdijkstra]

Hmm..

When I use the same setup like this with v1.0.0:

private RequestSpecification requestSpec;

        [SetUp]
        public void CreateRequestSpecification()
        {
            requestSpec = new RequestSpecBuilder()
                .WithScheme("http")
                .WithHostName("api.zippopotam.us")
                .WithBasePath("us")
                .Build();
        }

        [Test]
        public void CheckResponseStatusCodeAndJsonResponseBodyElementValue()
        {
            Given()
                .Spec(requestSpec)
                .When()
                .Get("/90210")
                .Then()
                .Body("$.places[0].state", NHamcrest.Is.EqualTo("California"));
        }

It works as expected. Again, can you please tell me what the endpoint is that RestAssured is trying to hit?

[bheemreddy181]

looks like i am using the formatUrlEnocoded branch not that master ( 1.0.0 ) - Can you try on that branch ?

[basdijkstra]

No, because that doesn't exist anymore. Can we leave this open until the next release? That should not take me more than a couple of days now, and since I've done quite a bit of work on the RequestSpecification, things might have changed for the better for you :)

[bheemreddy181]

Sure that works

[bheemreddy181]

[basdijkstra]

Yes, but the actual endpoint is only constructed inside the Send() method, that's where the RequestSpecification is applied.

See here:

rest-assured-net/RestAssured.Net/RA/ExecutableRequest.cs

Line 418 in 9d96a25

this.request = RequestSpecificationProcessor.Apply(this.requestSpecification, this.request, endpoint);

Can you debug into that? Or use Fiddler or WireShark to see what the outgoing traffic is, that's the actual endpoint.

[bheemreddy181]

this is what i see

[basdijkstra]

Thanks, that's what I was looking for. That's definitely not good.

Once again, let's park this until the next proper release. If it's still there, I'll try and fix that ASAP but I probably need you to publish this on GitHub (or send it to me via email: [email protected]) so I can reproduce it.

Even better would be to do that before the next release, so I can make sure it works and I don't ship something with a bug. Would that be possible?

[bheemreddy181]

Sure i can create an example on Github

[bheemreddy181]

https://github.com/bheemreddy181/restAssuredNetTest example repo

[basdijkstra]

Thanks. The error I'm getting when running your test with version 1.0.0 is slightly different:

System.AggregateException : One or more errors occurred. (The SSL connection could not be established, see inner exception.) ----> RestAssuredNet.RA.Exceptions.HttpRequestProcessorException : The SSL connection could not be established, see inner exception.

I've seen that with other HTTPS calls, too, and I'll address it in #13. Thank you for uploading that example!

Again, let's keep this open until version 1.1.0 is released and test again.

[bheemreddy181]

Sounds good thanks

[basdijkstra]

OK, I've found the problem (and another one in the logging, too). The problem is that the RequestSpecification port defaults to 80, which is not a useful value when you use https (it should be 443 in that case). When you change the port to 443, it works (or well, you get an HTTP 401 Unauthorized because your token value is invalid) as well as a NullReferenceException because there is no body to log and you call Log().All().

I've also tested it by adding .WithPort(443) to the RequestSpecification and that yields the same result, so the values from the RequestSpecification are applied to the request as expected, it seems.

I'll create separate issues for those, is it OK to close this one then, @bheemreddy181?

[bheemreddy181]

Gotcha - Sounds good to me wasn't that defaulting to port 80 before too ?

[basdijkstra]

Gotcha - Sounds good to me wasn't that defaulting to port 80 before too ?

Yes and it still does, because that's the default port for HTTP, but not for HTTPS. I might be better off not setting a default at all..

[basdijkstra]

Anyway, closing this one, we can always continue the conversation in the other issue.

[bheemreddy181]

is that ok to keep this request open until things get cleared on my side ?

[bheemreddy181]

Looks like you are framing the actual endpoint when the URI builder throws an exception, in my case I don't see an exception is being thrown here

[basdijkstra]

Yeah, happy to keep this open. It's really weird, though, because the UriFormatException should be thrown here according to the Microsoft docs (which are typically very accurate):

(from https://learn.microsoft.com/en-us/dotnet/api/system.uri.-ctor?view=net-7.0#system-uri-ctor(system-string))

The last sentence is key here. What you're passing in is a relative Uri, and that should throw the UriFormatException leading to the actual Uri being built from the RequestSpecification.

[bheemreddy181]

I think this is the issue dotnet/runtime#27813

[bheemreddy181]

I think you might need to do something of this sort
Uri uri = new Uri(url); try { string host = uri.Host; } catch (UriFormatException) { Console.WriteLine("Bad url: {0}", url); }

[basdijkstra]

That explains a lot of things... So, what .NET version are you using (the issue talks about .NET Core 2.1) and what operating system are you on? Just for my information :) I will need to find a way to fix / work around this.

[bheemreddy181]

I am on dotnet 6 and Operating system Mac OS.

[basdijkstra]

Thanks! It was only time before I'd run into cross-OS compatibility issues, I guess.. I'll have a look and see how to best fix this. I'll take your suggestion into account.

[bheemreddy181]

Sounds good thanks.

[basdijkstra]

Hey @bheemreddy181, I think I've fixed this now. Could you please retest with RestAssured.Net version 1.2.0-alpha, which is available as a prerelease through NuGet?

[bheemreddy181]

Sure will test sometime today.

[bheemreddy181]

Yes that worked. .RelaxedHttpsValidation() is what I am a bit confused on, why do I need to add that all the time for all requests. (Probably a different issue we can talk on)

[basdijkstra]

Thank you for verifying and happy to see that it works. The RelaxedHttpsValidation disables SSL checks, meaning that there’s no verification on whether or not there’s a valid certificate for the HTTPS connection. It’s an easy way to skip having to configure certificates for the connection if that’s not the point of the test.

[bheemreddy181]

I understand that token generation worked with RelaxedHttpsValidation before and all of a sudden this is a required in the implementation did something change around that ?

[basdijkstra]

Hey @bheemreddy181, token generation and SSL checks are two entirely different things. One has to do with user authorization, the other with network-level connection security.

If you think something's wrong here, please submit a new issue. No point in continuing a discussion in a closed issue.

[bheemreddy181]

Thanks for the explanation.Ya will do.