Latest version contains our own implementation of the .../execute endpoint since whatever those go-bindings library that was recommended doesn't include the content-type header.
Without this header, there is an error in one of the middleware components of the Piston API. Not sure why this doesn't effect the public Piston API.
router.use((req, res, next) => {
if (['GET', 'HEAD', 'OPTIONS'].includes(req.method)) {
return next();
}
if (!req.headers['content-type'].startsWith('application/json')) {
return res.status(415).send({
message: 'requests must be of type application/json',
});
}
next();
});
The current "custom" implementation of the Piston API endpoints seems more reliable to me. Perhaps this should later be refactored to its own package such as piston-wrapper for reuse in the future.
Refer to exec.go for how the implementation works.
Latest version contains our own implementation of the
.../executeendpoint since whatever those go-bindings library that was recommended doesn't include thecontent-typeheader.Without this header, there is an error in one of the middleware components of the Piston API. Not sure why this doesn't effect the public Piston API.
The current "custom" implementation of the Piston API endpoints seems more reliable to me. Perhaps this should later be refactored to its own package such as
piston-wrapperfor reuse in the future.Refer to
exec.gofor how the implementation works.