POST parameter encoding

[mbtaylor]

DALI section 4 lists a number of parameters and talks about submitting them to service endpoints, but I don't see anywhere it explicitly says, in general, how these must be encoded.

With GET as far as I know the only way to do it is using application/x-www-form-urlencoded in the query part of the URL (http://example.com?a=b&c=d) - though I don't know where in the standardsverse that practice is defined - so I guess that doesn't need to be said.

But for POST there are at least two options, application/x-www-form-urlencoded and multipart/form-data (for one definition of these see HTML 4.01 sec 17.13.4.1).

DALI sec 4.3.5 UPLOAD says that for inline uploads you have to use multipart/form-data. Some of the examples (e.g. sec 5.2 Synchronous Query) seem to show an ad-hoc(?) encoding that puts a name=value on each line without any encoding of spaces (I don't know whether this is literally intended/required to work, or whether it's just illustrative of the values). But other than that, I can't see instructions about POSTed parameter encoding in DALI or TAP.

Most TAP services seem to accept both multipart/form-data and application/x-www-form-urlencoded wherever parameters are POSTed. But I just encountered one that doesn't, and I don't know whether it is actually in violation of DALI/TAP or not.

So: should we add a note at the start of Section 4 saying that services are required to accept POSTed parameters in both application/x-www-form-urlencoded and multipart/form-data encodings?

[msdemlei]

On Thu, Aug 08, 2024 at 09:20:13AM -0700, Mark Taylor wrote: So: should we add a note at the start of Section 4 saying that services are required to accept POSTed parameters in both `application/x-www-form-urlencoded` and `multipart/form-data` encodings?

Yes. If nobody else volunteers within 4 weeks and nobody has major qualms with writing something to that effect, I will volunteer.

[pdowler]

Agreed.

In principle a single POST should be able to completely create a TAP job, including multiple params and multiple inline table uploads (!). If/when we have other APIs with a mix of params and inline content, they will also need to make sure multipart/form-data works.

! I'm not 100% certain that CADC TAP services actually accept multiple inline content, but if not it's a bug; the intent is that they do.

We may need to soften the language about content-type further, depending on P3T outcomes.