Skip to content
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

http.fetch always expects a reponse body #2831

Closed
KaKi87 opened this issue Nov 2, 2021 · 6 comments
Closed

http.fetch always expects a reponse body #2831

KaKi87 opened this issue Nov 2, 2021 · 6 comments

Comments

@KaKi87
Copy link

KaKi87 commented Nov 2, 2021

Describe the bug

http.fetch always expects a reponse body, therefore throws an error when there is none.

To Reproduce

Steps to reproduce the behavior:

  1. Run an http.fetch request that will return no response body and without defining responseType ;
  2. See the following error : Failed to parse response as JSON: SyntaxError: JSON Parse error: Unexpected EOF; try setting the responseType option to ResponseType.Text or ResponseType.Binary if the API does not return a JSON response.

Expected behavior

The request succeeds.

Platform and Versions (required):

Operating System - Linux, version 19.3 X64

Node.js environment
  Node.js - 14.18.1
  @tauri-apps/cli - 1.0.0-beta.10
  @tauri-apps/api - 1.0.0-beta.8

Global packages
  npm - 8.1.0
  yarn - 1.22.15

Rust environment
  rustc - 1.53.0
  cargo - 1.53.0

App directory structure
/dist
/node_modules
/.idea
/src
/src-tauri
/.git
/.parcel-cache

App
  tauri.rs - 1.0.0-beta.8
  build-type - bundle
  CSP - default-src blob: data: filesystem: ws: wss: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self' img-src: 'self'
  distDir - ../dist
  devPath - http://localhost:1234

Additional context

This error was spotted during the development of axios-tauri-adapter-test, the unit test project for axios-tauri-adapter.

Stack Trace

Not applicable

@lucasfernog
Copy link
Member

By default Tauri assumes a JSON response. It should work with ResponseType.Binary.

@KaKi87
Copy link
Author

KaKi87 commented Nov 2, 2021

Perhaps, although this is only a workaround, but not a fix.

@lucasfernog
Copy link
Member

Why is it a workaround if it's the API design? It might be a wrong design (we could argue that it should default to a binary response), but it's still the current design.

@KaKi87
Copy link
Author

KaKi87 commented Nov 2, 2021

Axios, for example, also uses json as default value for responseType (source) :

// `responseType` indicates the type of data that the server will respond with
// options are: 'arraybuffer', 'document', 'json', 'text', 'stream'
//   browser only: 'blob'
responseType: 'json', // default

Yet, it won't throw an error when there is no response body, because there is no obligation for it to exist.

Additionally, setting any value (like ResponseType.Binary) for responseType implies that a response body is expected, which is not the case, so it would be confusing.

But, I must also agree that Axios' behavior does not follow what I just said, as it ignores the lack of response body when one is expected, therefore, I alternatively suggest accepting null and/or something like ResponseType.None as a value for responseType that will prevent throwing an error when a request returns no response body.

@lucasfernog
Copy link
Member

I see your point now, and I agree with you.

@KaKi87
Copy link
Author

KaKi87 commented Nov 11, 2021

What about a step further : ResponseType.Any, which would follow Axios' behavior ? 🙃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants