-
-
Notifications
You must be signed in to change notification settings - Fork 7.3k
[Typescript] Add Headers to Request #10406
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Typescript] Add Headers to Request #10406
Conversation
| const requestContext = _config.baseServer.makeRequestContext( | ||
| localVarPath, | ||
| HttpMethod.{{httpMethod}}, | ||
| _config.baseServer.getHeaders() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like you always pass baseServer.headers to the baseServer.makeRequestContext call.
looks redundant - why don't baseServer.makeRequestContext does it internally - automatically?
amakhrov
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ksvirkou-hubspot thanks for the proposal! Could you provide an example of how you would use the new api to make a request with some custom headers?
|
Ah, I see. So the use case is setting some headers for a group of requests (maybe even across the whole app) - rather overriding headers for a specific single request you make. |
| return this.variableConfiguration | ||
| } | ||
|
|
||
| public setHeaders(headers: Headers): void { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Any thoughts about changing the name?
getHeaders return all headers - quite expected
But setHeaders does not set all headers, instead it's an additive operation merging new headers with existing ones
Consequently, it's not possible to remove a header previously added to the server configuration.
I mean - it resembles the existing setVariables method, true. Not sure if that interface was well thought through, though (e.g. getConfiguration instead of getVariables indicates otherwise :) )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right
I think It is better to change the function
@amakhrov
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
public setHeaders(headers: Headers): void {
this.headers = headers;
}
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or we can rename it to mergeHeaders or addHeaders
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
addHeaders sounds reasonable!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
@amakhrov
yes it is necessary for us |
amakhrov
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
|
@ksvirkou-hubspot can you please fix the ci failure? |
I think I can't fix it (It isn't the first PR to Open API Generator and every time I see this errors) |
merge master
Done |
|
@ksvirkou-hubspot please take a look at the circle CI failure: the current master at f5e8f54 seems to build correctly: https://app.circleci.com/pipelines/github/OpenAPITools/openapi-generator/13100/workflows/a8cc5b7e-e4b4-48b6-ac4a-13288c3ac369/jobs/26741 |
|
Wouldn‘t it make more sense to write a Middleware to set these headers? |
Maybe |
I've just run this test on my local machine and It works correctly |
|
I ran the tests locally and found the same 415 error on Not sure why it is happening, but Furthermore you should add some tests of your own to (at least) document the new feature. |
|
Hi @bodograumann, I'm trying to repro failing tests with |
|
According to the documentation you need to do: I don’t know why these tests are not automatically executed when running |
merge master
|
Hey everyone |
|
Works now afaics. Still think this should be done in a Middleware instead though. |
I didn’t create a new construction |
|
I didn’t want to start a new discussion. |
|
ok |
|
@TiFu what is your opinion here? |
|
Any Updates? |
|
Any Updates? |
|
Sorry for the long delay. |
|
Yes we can do it |
|
@ksvirkou-hubspot I guess it could be something like this (using your original code snippet as the basis): |
|
Sorry for the delay! Given that this can easily be implemented in a Middleware (as demonstrated by @amakhrov), I would suggest to not merge this PR. I think this use case is a bit of a poster child for why we added the Middleware option. |
|
Thanks @TiFu |
fixes #10368
PR checklist
This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
These must match the expectations made by your contribution.
You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example
./bin/generate-samples.sh bin/configs/java*.For Windows users, please run the script in Git BASH.
master(5.3.0),6.0.x