When a user specifies a ResponseHandler to intercept processing of the response object in any of the Send commands, the user must provide the logic to return a Parseable and handle all the error processing, edge cases in serialization e.t.c

We should allow users to have access to the response object while allowing the net_request_adapter to process the request to completion as its possible to have users who only want to access parts of the response e.g response headers.

The proposal seeks to solve

1. Allow a ResponseHandler to return a nil value without causing a casting error
2. Allow users to define a response handler that is not final, i.e users can define a handler that will allow access to the raw http.Response while still delegating the responsibility to return a parse able object from the adapter

This issue is a follow-up for #70 . Thanks for the quick solution for the original issue. What is the opinion on not setting a context timeout if the http timeout is 0?

Since the library sets the timeout to 100, I think we can assume that if we get a value of 0 for http timeout, it is because the user explicitly overrode the value to 0. As of now, if the user sets the timeout to 0 assuming it to get infinite timeout (for example to download large files) it will fail for all requests as it will end up setting a context deadline 0s into the future.

Do let me know if there is some specific reasoning behind the original 100s timeout that I am missing. I was not able to find the reason for the original change in the linked issue.

/cc @rkodev

Related to: #81

I noticed that the request headers are only being added to the returned error if the function returns prematurely.
Would be nice if someone could take a look at it.

Hi everyone! 👋
I started building a new SDK in Go for Apicurio Registry, my experience performing a GET has been completely smooth, great job!

It required quite some digging to find out that an interceptor for compression is enabled by default, and that's surprising, I haven't found a better way to disable it than creating a new client without it:

	adapter, err := kiotaHttp.NewNetHttpRequestAdapterWithParseNodeFactoryAndSerializationWriterFactoryAndHttpClient(
		&authProvider,
		nil,
		nil,
		kiotaHttp.GetDefaultClient(
			kiotaHttp.NewRetryHandler(),
			kiotaHttp.NewRedirectHandler(),
			kiotaHttp.NewParametersNameDecodingHandler(),
			// NewCompressionHandler(),
			kiotaHttp.NewUserAgentHandler(),
			kiotaHttp.NewHeadersInspectionHandler(),
		),
	)

My expectation would be: compression should be disabled by default and we should document how to toggle it on and off

Hello all,

I ran into an issue where overriding the default transport in net/http (net/http.DefaultTransport) results in the follow panic:

interface conversion: http.RoundTripper is *otelhttp.Transport, not *http.Transport

I traced the issue back to

By casting to the concrete type *nethttp.Transport, you preclude the use of other valid implementations of http.RoundTripper. By not checking the conversion, this line results in a panic.

From microsoftgraph/msgraph-sdk-go#302 (comment) and #24 , looks like the library by default adds a 100s timeout if none is present. I understand that we can pass a context with a Deadline, but this becomes a problem when we have to do this for all requests. I was hoping to use the Timeout in http client instead of a context deadline. Is there some way to globally override this 100s timeout?

Other references:

• microsoftgraph/msgraph-sdk-go-core#6
• #24

originally reported in microsoft/kiota-http-python#179
We add those cases as unit tests and correct the implementation so it doesn't impact query parameters values

related to microsoft/kiota#4025
add a 3rd case in the error handling of the request adapter for XXX (must be the 3rd in the order, first sepcific code, then 4XX or 5XX depending on the first number, then XXX)

follow up to microsoft/kiota#4367
and microsoft/kiota#4190

Implement a unit test with a 304 response, no location header, check the request adapter returns null and doesn't throw.
Most likely this line will need to be adapted.

My team and I have discovered some resources that take too long to return data for certain page sizes. These resources consistently result in 503 errors with no body content being sent back. The retries in the default graph client don't get us passed the 503s either. When using the kiota-serialization-json-go library and other graph SDK libraries to communicate with the Graph servers we only get an error of "content is empty" back from graph SDK in these situations

This is problematic because we lose information about the HTTP status code. For example, we've found that if we see consistent 503s with no content returned we can reduce the requested page size to make progress. This strategy would probably not make sense if the status code was a 4xx error though

Would it be possible to update the graph SDK (I'm unsure which repo the update would be in) to somehow return the HTTP status code? We've worked around the issue for the moment by adding our own middleware to the graph client and explicitly checking for no content and returning an error, but that feels a bit heavy handed

As an additional note, depending on which graph SDK repo the fix is made in, other repos may need updating as well. For example, all the serialization libraries contain the line errors.New("content is empty") like I linked above

Current implementation of the Response Handler requires the instance to be passed via the context object.
However the function context.WithValue returns a pointer to a different instance on the object instead of the original pointer.

A fix is required to return the actual pointer value

See microsoftgraph/msgraph-sdk-go#485

I'm trying to get the contents of a drive item. When I use the SDK client to make the call, I get a 400. However, when I curl the same URL, it works.

Details

Here's roughly what happens:

1. Client calls https://graph.microsoft.com/v1.0/drives/<drive-id>/items/<item-id>/content.

   graphClient.DrivesById(driveId).ItemsById(itemId).Content().Get(ctx, nil)

2. API returns 302 to https://mytech.sharepoint.com/_layouts/15/download.aspx?UniqueId=ugly-gu-id&Translate=false&tempauth=some.jwt.token&ApiVersion=2.0
3. After client redirects, the API returns 400 with the message

   <h2>Our services aren't available right now</h2><p>We're working to restore all services as soon as possible. Please check back soon.</p>0123

However, If I curl the redirect URL, e.g.

curl "https://mytech.sharepoint.com/_layouts/15/download.aspx?UniqueId=ugly-gu-id&Translate=false&tempauth=some.jwt.token&ApiVersion=2.0" > my.docx

the API returns a valid file.

Someone in the original thread suggested that the problem is here:

The fix should probably go here:

kiota-http-go/redirect_handler.go

Line 158 in 53e6b69

result := request.Clone(request.Context())

The URL's host is checked in order to drop the Authorization header if it's different, but the Host: header is never updated.