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

Wrong HTTPS status error messages are displayed in browser / Pjax repeats request even if HTML present #357

Open
misog opened this issue Aug 26, 2022 · 1 comment
Labels
duplicate This issue or pull request already exists

Comments

@misog
Copy link

misog commented Aug 26, 2022

Describe the bug

Hi, this issue is caused by Pjax revisits as described here: #342

The problem is worse however. For example, when user uploads too large file, the server response "413 Request Entity Too Large" should be displayed to user. For example, this is returned by nginx:

<html>
<head><title>413 Request Entity Too Large</title></head>
<body>
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx</center>
</body>
</html>

But now Pjax tries to revisit that URL and that will produce this error instead:

Oops! An Error Occurred
The server returned a "405 Method Not Allowed".

The core of the problem is that Pjax makes additional request without user consent (revisit).

To reproduce

  1. Make any form POST request to URL in a way that generates status code >=400 and where the URL is POST-only
  2. See the error message
  3. The error message is wrong (Pjax tries to GET that URL which is POST-only)

Expected behavior

  • Correct server error message should be displayed in the browser.
  • Pjax should not repeat a request if there is HTML content to show in the first response.

Possible solutions

Pjax probably checks mime type or something in header or status code to decide if to repeat request.

One solution to this problem is to check if there is any HTML content even if there is error status and then NOT repeat request (revisit) and instead run document.write(htm_error). Or user-provided handler for error output can be run (where I would call document.write and show the HTML of the error message).

@PaperStrike
Copy link
Owner

PaperStrike commented Feb 6, 2023

Technically a duplicate of #342, it's all about fetch error handling.

@PaperStrike PaperStrike added the duplicate This issue or pull request already exists label Feb 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

2 participants