-
-
Notifications
You must be signed in to change notification settings - Fork 135
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
Feature Request: URL upload - Content-Type Update #181
Comments
This was referenced Feb 17, 2022
Hey @dgmartin, You need a new settings option called "Content Type" that can be set to "text/plain" or "application/json" correct? I think we are currently are not setting the content type at all. If this is correct, would you be able to send a PR for this? |
dgmartin
added a commit
to dgmartin/design-tokens
that referenced
this issue
Feb 23, 2022
dgmartin
pushed a commit
to dgmartin/design-tokens
that referenced
this issue
Feb 24, 2022
…fault setting for Content Type.
dgmartin
pushed a commit
to dgmartin/design-tokens
that referenced
this issue
Mar 3, 2022
dgmartin
pushed a commit
to dgmartin/design-tokens
that referenced
this issue
Mar 8, 2022
dgmartin
pushed a commit
to dgmartin/design-tokens
that referenced
this issue
Mar 8, 2022
lukasoppermann
pushed a commit
that referenced
this issue
Mar 9, 2022
* #181: Added Content Type setting to URLExport flow. * #181: Added testing for Content Type settings. Added default setting for Content Type. * #181: Added documentation. Co-authored-by: Dan Martin <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The Problem:
Currently when selecting the option to upload to a URL you have three options: (Github) token, Basic auth, and Bearer token auth. When trying to make a call using a Gitlab pipeline trigger URL the server can be reached only using the Github Authorization or Basic Authorization configurations however in both cases the payload is rejected due to fact that the "Content-Type" header is set as "text/plain;charset=UTF-8." After testing this same request/payload using postman I found that changing this header value to "application/json" would let the request through and a user could retrieve the payload under the "TRIGGER_PAYLOAD" environment variable in the CI/CD Pipeline run.
The Solution:
The ask here is to include a settings change for the "Content-Type" header to allow the end user to update this to "application/json." This would be similar to the way the "Accept" header can currently be overridden. Alternatively because the call is already passing json perhaps it makes more sense to make "application/json" the default value anyway.
More information on the use with Gitlab webhook can be found here. Note the webhook URL format is slightly different than the URL used for form submission
The text was updated successfully, but these errors were encountered: