[rhttp] Headers and Parameters Cannot Be Removed From a Request
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 7.8k
- Forks
- 6.9k
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 442
Description
Extension
https://www.raycast.com/SebastianJarsve/rhttp
Raycast Version
2.1
OS Version
No response
Description
Description
When creating or editing a request, headers and parameters can be added but cannot be removed.
If a header or parameter is added by mistake, the only workaround is to delete the entire request and recreate it.
Steps to Reproduce
- Create a new request.
- Add a header or parameter.
- Try to remove the added entry.
Actual Behavior
There is no option to remove the header or parameter.
Expected Behavior
Each header and parameter should have a remove or delete action, such as a button next to the entry.
Impact
A small input mistake can require the user to delete and recreate the entire request, including all its other configuration.
Suggested Fix
Add a remove action for every header and parameter entry, and allow empty or accidentally added entries to be cleared before saving.
Attachment
The screenshot shows an accidentally added Accept header that cannot be removed.
Steps To Reproduce
- add a header
- save the request
- try to remove that header from the request
Current Behaviour
No response
Expected Behaviour
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by opening the linked rhttp extension and reproducing the issue in the request editor: add and save a header or parameter, then try to remove it. Done means each entry has a remove action and accidentally added or empty entries can be cleared before saving.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 70/100