cfug
OPTIONS request body error
New Issue Checklist
- [x] I have searched for a similar issue in the project and found this, but it was closed due to inactivity.
Issue Info
| Info | Value | |
|---|---|---|
| Platform Name | dart/flutter (all platforms) | |
| Platform Version | noted below | |
| Dio Version | 4.0.4 and older | |
| Android Studio Version | noted below | |
| Repro rate | all the time (100%) |
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 ordinary POST. However, Dio as of version 4.0.4 does not support OPTIONS 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 add OPTIONS to the allowPayloadMethods 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 with retrofit2:
@HTTP(method = "OPTIONS", path = "/mypath", hasBody = true)
suspend fun getMyResponse(@Body request: MyRequest): MyResponse
Environment
- Device: Chrome
- OS: Win 11 Pro
- Package version: flutter_stripe: ^2.1.1 flutter_stripe_web: ^0.1.1
- Flutter version: 2.8.1
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)
Actually I see there was a similar discussion about GET #1336, #252, #893, I think it would be great if you could just let use use body with any method, so that these issues don't come up in the future.
At the risk of sounding harsh, why is this issue still open and discussed about? I'm all for following specs, but not if it prevents (many) people from solving their issues, especially if it doesn't detrimentally affect anyone who doesn't need or want to use it - and this is literally a one line change!
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 dio, named diox.
The new package contains the PR of the fix.
Please refer to https://pub.dev/packages/diox/versions/5.0.0-dev.1 to use the fork.
You can also see why we're working for a hardfork at https://github.com/cfug/diox/issues/29 and https://github.com/flutterchina/dio/issues/1607.
