-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
OPTIONS request body error #1422
Comments
I think we should do this, a lot of people are asking. |
At the risk of sounding harsh, why is this issue still open and discussed about? At 90% percent of project completion, after having everything networking related set up and working - including parsing, interceptors, caching, error handling etc., I come across one endpoint from a third-party client (we can't change it) which requires us to send a request body on a GET request, and now I have to maintain a fork of Dio just to change one line of code. Please consider removing this restriction ASAP, thanks! |
Hi everyone! We've made our hardfork repo public and published a new version of |
New Issue Checklist
Issue Info
Issue Description and Steps
The API of our business partner has
OPTIONS
requests with a body, sometimes a form, sometimes json, sometimes bytes, very similar to an ordinaryPOST
. However,Dio
as of version4.0.4
does not supportOPTIONS
requests with a body, it just skips the data altogether. Here's the relevant code: permalink.We really can't change the API, since it isn't ours, and our project is just stuck indefinitely because of this. We've made too much of a commitment to
Dio
, writing dozens of requests, so switching to a different package is out of the questions. Can this be fixed and can there be a local solution that we can apply in the meantime? Maybe @kuhnroyal can suggest something? I'm a bit afraid to just addOPTIONS
to theallowPayloadMethods
list, as I am not aware of the full consequences this will bring. Regardless, it would be great to have an official supported way to do this instead of manually editing the source code after every package update / reinstall.As for the "legality" of using a body with
OPTIONS
, I don't think it's reasonable too, but it works fine in other platforms. Here's a kotlin example withretrofit2
:Environment
Additional context
[√] Flutter (Channel stable, 2.8.1, on Microsoft Windows [Version 10.0.22000.434])
• Flutter version 2.8.1 at C:\Soft\Android\flutter
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision 77d935af4d (7 weeks ago), 2021-12-16 08:37:33 -0800
• Engine revision 890a5fca2e
• Dart version 2.15.1
[√] Connected device (3 available)
• Chrome (web) • chrome • web-javascript • Google Chrome 97.0.4692.99
IDE
Android Studio Bumblebee | 2021.1.1
Build #AI-211.7628.21.2111.8092744, built on January 19, 2022
Runtime version: 11.0.11+9-b60-7590822 amd64
VM: OpenJDK 64-Bit Server VM by Oracle Corporation
Windows 10 10.0
GC: G1 Young Generation, G1 Old Generation
Memory: 3072M
Cores: 16
Registry: external.system.auto.import.disabled=true, ide.instant.shutdown=false
Non-Bundled Plugins: Dart (211.7798), andrasferenczi.dart-data-plugin (0.2.0), org.jetbrains.kotlin (211-1.6.10-release-923-AS7442.40), io.flutter (63.2.2)
The text was updated successfully, but these errors were encountered: