Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Content-Disposition, be permissive sans whitespace

Open
#7 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
25/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Domain
api

Research direction

No source file, test, or entry point is named. Start by locating the server's Content-Disposition parsing and compare the working CLI header with the Pharo header; done means both forms are accepted without a 500 response, with coverage for the no-whitespace variant.

Written by the indexing model from the issue text.

Description

As noted here, while writing a GUI client for Pharo I discovered the server is quite picky in requiring a whitespace following "form-data;" in the "Content-Disposition:" field.

After a couple of hours hunting various RFCs I couldn't find that requirement anywhere. While Pharo will be able to work around it, but this situation may impede others trying making a custom client, so consider being more permissive in the line structure.

Here is the pertinent line extracted from a Wireshark captures...

CLI generated the following which works fine...
Content-Disposition: form-data; name="files[]"; filename="myfile.txt"

Pharo generated the following and gets "500 INTERNAL SERVER ERROR"...
Content-Disposition: form-data;name="files[]";filename="myfile.txt"

A diff of the full requests plus library code change is here... https://www.diffchecker.com/ETIfCUzx
Note its actually only the first space-after-semicolon that it the problem.

Dominant language
No language data
Stars
0
Forks
4
Avg merge
3m
Merged PRs (30d)
1

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from exercism/backlog

All issues in exercism/backlog

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.