microsoft / kiota-http-go Goto Github PK
View Code? Open in Web Editor NEWKiota http provider implementation for Go with net http
Home Page: https://aka.ms/kiota/docs
License: MIT License
Kiota http provider implementation for Go with net http
Home Page: https://aka.ms/kiota/docs
License: MIT License
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
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.
kiota-http-go/nethttp_request_adapter.go
Lines 811 to 813 in b162cb6
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.
Here's roughly what happens:
https://graph.microsoft.com/v1.0/drives/<drive-id>/items/<item-id>/content
.
graphClient.DrivesById(driveId).ItemsById(itemId).Content().Get(ctx, nil)
302
to https://mytech.sharepoint.com/_layouts/15/download.aspx?UniqueId=ugly-gu-id&Translate=false&tempauth=some.jwt.token&ApiVersion=2.0
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
The URL's host is checked in order to drop the Authorization header if it's different, but the Host: header is never updated.
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
Line 63 in 51c8f26
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.
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
ResponseHandler
to return a nil value without causing a casting errorhttp.Response
while still delegating the responsibility to return a parse able object from the adapterMy 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
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.
kiota-http-go/nethttp_request_adapter.go
Line 746 in 7f1b45b
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
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)
kiota-http-go/nethttp_request_adapter.go
Line 424 in fbaf921
if err != nil {
return err
}
return nil
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
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
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:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.