How can one access the request body in a POST or PUT block? The following only seems to work for x-www-form-urlencoded parameters:

POST: '/' -> [ :req | ^(req at: #foo)]

if I POST: foo: something as x-www-form-urlencoded.

But what if I want to post a JSON body, like {"foo": "something"}? I can't seem to find a way to access that.

Hi, are you planning to migrate the project to Github?

Can I help?

One small issue left because of merging of #20 from @demarey

some toolbar button labels are too long. Maybe we should change them:

@zeroflag / @demarey what do you think?

These no longer work with Pharo 10.

It would be nice to have Teaspoon working on Pharo 8.

If you define a route and do a request against this route but using an unexpected HTTP method, Teapot is responding with 404 Not Found.

As far as I understand in that case the response should be 405 Method Not Allowed, for example:

Teapot on
    GET: '/welcome' -> 'Hello World!';
    start.
	
ZnClient new
	beOneShot;
	enforceHttpSuccess: true;
	options: 'http://localhost:1701/welcome' asZnUrl  

Here the resource exists, but the HTTP method used is invalid, so I think this should return 405.

I think part of the problem is that TeaDynamicRouter assume that if no route can handle the request then the resource is not found; but in this case the resource exists, what it's invalid is the Method used.

References:

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405
• https://tools.ietf.org/html/rfc7231#section-6.5.5

The baseline conflicts with the ZincHTTPComponent baseline that is loaded in the Pharo 11 base image. The dependency for this project is pointing to an incorrect repo path. According to the Zinc project it should say:

Metacello new
repository: 'github://svenvc/zinc/repository';
baseline: 'ZincHTTPComponents';
load.

this line in the baseline: 'ZincHTTPComponents' with: [ spec repository: 'github://svenvc/zinc' ];
should probably be replaced with: 'ZincHTTPComponents' with: [ spec repository: 'github://svenvc/zinc/repository' ];

Cupboard should be a spec presenter displaying a list of Teapots and allowing actions on the selected Teapot

As the title says, how do I get rid of a Teapot instance?

Hi,

I registered the following routes:

GET -> '/data-streams/identifier:IsUUID/data-points'
GET -> '/data-streams'
GET -> '/data-streams/identifier:IsUUID'

and performing a GET on '/data-streams' I've got a MNU from TeaPadding.

IsUUID implementation of #matchesTo: and IsInteger look alike, I changed the regex pattern.

In the stack I found a TeaRequestMatcher trying to match the request's URL '/data-streams' to '/data-streams/identifier:IsUUID/data-points' by padding the segments of the first one and getting the following collection ('data-streams', TeaPadding, TeaPadding).

Then tries to match them from left to right until it gets the MNU trying to match the type constraint IsUUID to the first TeaPadding.

I think I can easily fix it by changing the IsUUID class>>#matchesTo: implementation taking into account that a TeaPadding can show up but I find hard to image that I'm the first one running into this issue.

Am I missing something?

testTralingSlash
	self pattern: '/a/b' matches: '/a/b/'.

It looks like the trimTrailingSlash method fails to trim the ending / because the last segment of the url is no longer a string but a character ($/).

trimTrailingSlash: urlSegments 
	^ (urlSegments isNotEmpty and: [ urlSegments last = '/' ])
		ifTrue: [ urlSegments allButLast ]
		ifFalse: [ urlSegments ]

Hi. I realized that there is a problem when retrieving the form-based request parameters performed with ajax. More details and my solution here: https://stackoverflow.com/questions/62971100/how-to-pass-a-non-url-request-parameter-to-smalltalk-teapot-from-ajax-call

Well, in fact, I had to extend the request class so I can access the znRequest instance to ask for the entity and its content.
Best,

The method Base64MimeConverter class>>#mimeDecodeToBytes: called from TeaIconProvider class>>#teapotIcon has been deprecated.
Please use #base64Decoded now. See issue #21937

After execute the test on package Teapot-Test, there are 11 teapot instances that doesn't are GC collected. All server are closed, as can be see in the teapot inspector,

but remains in the image.

Is there a method to remove them from the image?

Hi Attila, I've started to use Teapot for a backend and it feels really great. Thanks for sharing all this.

While working with the authorization of this API, I've faced an issue on exceptions. I've noticed that any answer that was using abort: was having CORS issues.

Digging into it I've came across the initialization of Teapot itself:

Teapot>>initializeOptions: optionsDictionary
	dynamicRouter := TeaDynamicRouter new.
	staticRouter := TeaStaticRouter new.
	compositeRouter := TeaCompositeRouter routers: {dynamicRouter. staticRouter}.	
	defaultOutput := self responseTransformer: (optionsDictionary at: #defaultOutput ifAbsent: #html).									
	self exception: TeaAbort -> [ :abort :req | abort response teaTransform: [ :same | same ] request: req].

That exception: TeaAbort is deciding on the answer and because is the first error handler, even if you app tunes it to add headers, this one will be performed.

For these interested in a solution right now:

It doesn't have accessors to manipulate that from the outside so for now in my app I've solved it with this horrible hack:

App>>newHttpServer

	| newServer |
	newServer := Teapot configure: { 
			             (#defaultOutput -> #json).
			             (#port -> self class port).
			             (#debugMode -> self class debugMode).
			             (#bindAddress
			              -> (NetNameResolver addressForName: self class bind)) }.
	((newServer instVarNamed: 'compositeRouter') instVarNamed:
		 'errorhandlers') removeLast.
	^ newServer

So later the App can:

App>>setExceptionHandlers

	| origin |
	self teapot exception: TeaAbort -> [ :abort :req | 
		origin := req headers at: 'origin' ifAbsent: [ '*' ].

		abort response headers
			at: 'Access-Control-Allow-Credentials' put: 'true';
			at: 'Access-Control-Allow-Origin' put: origin;
			yourself.
		abort response teaTransform: [ :same | same ] request: req ].

With this, the frontend will not be blocking the 401 because of CORS.

I'd be happy to open a pull request with a change to make this but without needing to rely on hacking Teapot. Let me know if you have any suggestion on how. Thanks again.