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.

[gmantele]

I agree with you and @msdemlei . This should be documented in DALI, whatever encoding must be used. In practice, I also tend to support both, just by security. So, I would tend to say that both should be supported as clients may have different practices.

Then, how would it be specified in an OpenAPI document? Duplicated entries or just listing supported parameter encoding?

[mbtaylor]

Fixed by #61.