Proposal to create a universally accepted type for URLFormEncoding

Development Networking
1

There are several solid implementations of URLEncodedForm encoding/decoding floating around the Swift ecosystem. They currently exist in Hummingbird, Alamofire, Vapor, and the legacy Vapor URL-encoded form repo, plus a handful of community forks derived from Vapor's original implementation. This makes it difficult to benefit from one of these types without bundling an entire framework.

I'm curious if anyone in the community has encountered a similar issue and thinks that we should move to either:

  1. A dedicated target within an existing package that can be depended on without pulling in the full framework, or

  2. A separate standalone repo/package focused solely on URLEncodedForm encoding/decoding

Personally, I feel that this is a similar need to JSONEncoder/JSONDecoder. It seems strange to have separate implementations that all have the same goal when URL encoded forms (RFC 3986) is a widely accepted standard.

Right now, developers in those situations are left choosing between pulling in a heavy framework dependency, maintaining a fork, or rolling their own. A clean, standalone package would fill this gap. It also minimizes the security risk of different versions of the URLEncodedForm floating around, which I imagine is generally less likely from a security perspective.

Please let me know thoughts. Thanks!

5 Likes
2

We can discuss what this should look like and probably discuss this in a future networking workgroup meeting.

But if we're going to use URL types and URLQueryItems etc, this should probably just be added to FoundationEssentials

4 Likes
3

+1 to living in FoundationEssentials and working closely with Networking folks for the design

Using [URLQueryItem] or a thin wrapper type like URL.EncodedFormQuery to encode to/from [URLQueryItem] seems like it would be a good fit for the flat name/value layer. We could also investigate StringProtocol extensions like adding/removingURLFormEncoding().

Designing a URLEncodedFormEncoder for arbitrary types carries a bit more complexity since there's no single standard for encoding nested structs, arrays, bools, etc. That's definitely an area where insight from the Networking workgroup and implementers will help tremendously.

In either case, we'll want to discuss what parsing semantics (leniency/WHATWG adherence) and configuration options these APIs should support.