Describe the bug After upgrading to 7.2.2 the redirect from our IDP no longer works. I'm getting a 404 after a POST request is made to https://localhost:8080 I can't provide a reproduction as it requires authenticating against an IDP. Currently using 7.1.12. Switching to any 7.2 version results in this issue. Reproduction https://idonthaveone.com Steps to r…
Freev0.1.0Chrome extension
Long thread;
short answer.
Issue TL;DR puts a button next to the title of every public GitHub issue and pull request. Click it to see where the discussion landed, what was decided, what is still open, and what changed since you last looked.
86 KB. Not in the Chrome Web Store yet; install it in four steps.
The same issue when you come back to it.
Server Proxy Urls Don't Respect changeOrigin Setting in Vite Config in Version 7.2.2 #21117
We need more information to solve this on our side (sending a PR from you would be much easier). Would you provide more information?: - Which commit caused the issue? (you can use pkg.pr.new for the prebuilt packages) - How do you use the IDP with your Vite app? (e.g. proxy option, redirect via location.href =, reverse proxy in front of Vite server) - What…
I debugged the network flow and see the problem, but don't understand why it's happening. The login flow looks like this: 1. In the UI code we call an endpoint on the server to test if the user is logged in: 2. This call is proxied to our api gateway like so: 3. When this endpoint indicates the user is not logged in, we redirect to the login page like this:…
I guess it's related to vitejs/vite#20869 (sagemathinc/http-proxy-3#33). Would you try setting server.https: false? If that works, then it's probably related to that PR.
How is that GET https://localhost:8080/api/app-user/me HTTP 1.1 200 OK generated? Does it use some headers to construct that value?
It's not that straightforward to set server.https: false. The api gateway is not configured to serve over http. All the proxy urls would have to change in addition. Not saying it's not possible, but it would require several changes, including the B2C configuration. The call to https://localhost:8080/api/app-user/me is simply called in a React hook as part o…
I tried setting the changeOrigin setting for each proxy url and this had no effect in 7.2.2. The server always receives the proxy url https://localhost:5005/... However when using 7.1.12, the setting is respected. This is a related change of behavior. Feels like a bug to me.
@sapphi-red I did not mean to close this.
Ah, ok. I guess it's because this part of the code doesn't work with the new http2 support feature (sagemathinc/http-proxy-3#33). https://github.com/sagemathinc/http-proxy-3/blob/ce8f922ebbbc8ab3c3c7252e3460b791b3a772eb/lib/http-proxy/common.ts#L140-L145 Hmm, but IIUC it's not possible to set a Host header with HTTP2 and the successor, the :Authority pseudo…
It's not currently implemented, but there is support for it. Before I head down this route, are you certain changeOrigin will no longer work going forward? Using the X-Forwarded-Host header is the only way deal with this now? If so, at the very least you need to remove the changeOrigin property, no? Mention of this in the release notes would be useful too.
As far as I can think of... I'm not an expert of HTTP spec so I don't have a strong confidence. It still works if the Vite server is running in HTTP 1.x or the proxy target is listening on HTTP 1.x. Yeah, I think we should add it to the description of the option and in the related PR.
@sapphi-red I attempted the xfwd approach but it did not work. 1. I added the xfwd and changeOrigin properties to my proxies: 2. I then added the following to my OnRedirectToIdentityProvider handler: 3. However, the x-forwarded-host header is empty. 4. The Referer header has the value I need and if use it like so, I am able to successfully login. This was j…
I settled on the following which is a bit of a hack just so I can upgrade. I don't think this should be necessary. I kept the proxy setting the same: And added the following to my api gateway: Sign in: Sign out: Can vite please investigate this issue?
You're not. We are also affected by this.
I am also affected.
Issue for me as well. Stopped working in 7.2.
I found the places that may be the reason of this issue. I fixed that in #21134. Would someone try if vitejs/vite#21134 (comment) works?
It seems #21134 doesn't work. Unfortunately, I run out of ideas here. So this is impossible to fix by me (or other contributors) unless someone creates a self-contained reproduction.
I can come up with a minimal package.json and vite.config.js when I have some time, but let me explain briefly how it can be reproduced: - run a http echo server: PORT=8081 npx http-echo-server - point the vite proxy to this server - observe different responses, for e.g. versions 7.1.9 and 7.2.2: 7.1.9: 7.2.2: proxy config is along the following lines:
Actually, it seems to be related to https. If I run vite without, I get consistent results: Setting changeOrigin: true correctly changes the host header in this case.
I now have a minimal reproduction here, with the steps required to run it: https://github.com/nilsalex/vite-xff-bug https://github.com/nilsalex/vite-xff-bug/blob/main/README.md
vitejs/vite#21134 worked for vitejs/vite#21117 (comment).
@sapphi-red can you please elaborate? I tested #21134 and it did not work for me.
@mschaefer-gresham I tested vitejs/vite#21134 with the reproduction made by @nilsalex (vitejs/vite#21117 (comment)) and the x-forwarded-* headers and the host header was the same value with the one output with Vite 7.1.9.
@sapphi-red both @nilsalex and I both reproduced the issue. @nilsalex reproduced it above using the reproduction you used, and I reproduced it independently. How do we explain this?
I can confirm, my reproduction looks good with the PR in all permutations (with/without https, with/without changeOrigin). I still have to test my actual use case, which is very similar to @mschaefer-gresham
@mschaefer-gresham Maybe there's something unique to your environment? or possibly the override is not working.
@sapphi-red @nilsalex I tested the reproduction from @nilsalex and indeed the headers are there. I also created a https echo server in dotnet core and the headers are there as well (I replaced the echo server in the reproduction). But I re-tested my actual application and the x-forwarded-host header is not there. I looked at the headers inside the login and…
For me, the issue with .NET seems to be resolved: Now what's different for me is that I proxy to an http endpoint (not https).
I found the issue in my gateway. It was this: If I remove this the headers are available. This is odd because if I understand the documentation, the whole point of ForwardedHeaders is to tell dotnet to trust these forwarded headers from proxy servers.
I've released a new version (1.23.1) of http-proxy-3 with the fix merged.
#21134 & sagemathinc/http-proxy-3#43
Real public threads, summarized by the extension's own rules. Point at anything in the panel to find where it came from.
It remembers where you stopped reading.
The first time you open a thread, Issue TL;DR notes the last reply and the status you saw. Come back half an hour or more later and the panel starts with what is new: the replies since then, who wrote them, and whether the issue was closed, reopened or merged in between.
When you have caught up, Mark all read moves your place to now. Your place is kept in Chrome on your computer, one small record per thread.
Read before New since then. Taller bars are maintainer replies.
What the panel tells you
Six answers in the order you need them, each linked back to the comment it came from, and one button to take them with you.
- Conclusion
One sentence: where the thread stands and what resolved it, with the number of replies and the last activity.
- Status
Open, closed as completed, closed as not planned, merged or draft, with labels and review verdicts on pull requests.
- Decisions
What maintainers settled, from their own words and from approving or changes-requested reviews.
- Open questions
Questions on open threads that nobody has answered yet.
- Next steps
Unchecked task-list items, recent requests, and whose turn it is.
- Key comments
The replies that matter most, ranked by maintainer role, reactions, linked fixes and reproductions, each linked.
- Copy Markdown
The whole summary with links, ready for a standup note, a hand-off or a pull request description.
Private by default
Issue TL;DR has no backend. Everything it knows about you stays in your browser.
- No account, no sign-in
It reads public threads from GitHub's API without your GitHub credentials.
- No server of ours
The summary is built inside your browser. The only requests go to api.github.com.
- No tracking
The extension and this site have no analytics, no ads and no cookies. Usage counts in Options stay on your computer.
- Claude is optional and uses your key
Add your own Anthropic API key in Options to get Summarize with Claude. The thread then goes from your browser straight to Anthropic, only when you press it.
Install
Issue TL;DR is not in the Chrome Web Store yet, so you load it into Chrome yourself. It takes about a minute, and works the same way in Edge, Brave and Arc.
- Install Issue TL;DR 0.1.04 steps
- 1Download and unzipDownload for Chrome
Unzip it somewhere it can stay, such as your Documents folder.
- 2Open the extensions page
Paste this into the address bar. In Edge, use
edge://extensions. - 3Turn on Developer mode
The switch is in the top right corner of the extensions page.
- 4Load the folder
Click Load unpacked and choose the unzipped
issue-tldrfolder. Then open any public issue, for example vitejs/vite#21117, and click TL;DR after the title.
Questions
Does it cost anything?
No. The extension is free. If you turn on Claude summaries, Anthropic bills your own API key for those calls.
Does it work on private repositories?
Not yet. This version reads public issues and pull requests on github.com only, because it never asks for your GitHub credentials.
Why does it sometimes say to wait?
GitHub allows 60 requests an hour per network address without sign-in, and opening a thread uses two to four, so most people never notice. Heavy use, or many people sharing one office network, can reach it. If you do, the panel tells you when it resets.
How good are the summaries without Claude?
The built-in rules are quick and predictable, and do best on threads where maintainers state decisions plainly. On very long or non-English discussions they find less; that is where Summarize with Claude helps.
Does it change anything on GitHub?
No. It only reads. It never comments, reacts, subscribes or edits.
Is there a Firefox or Safari version?
Not yet. It runs in Chrome and in browsers built on Chromium, such as Edge, Brave and Arc.
Does it notice edited comments?
Not yet. Since last visit counts new replies and status changes; a comment edited after you read it is not flagged.