Many thanks for your contribution.

Returning 400 Bad Request status codes in case of syntax error is indeed a good idea.
Are you using this return code in some way ?

However, it seems that "badRequestOnError" is unused in:
void sendDiagram(String uml, int idx, boolean badRequestOnError)

Could you remove it from your merge request ?
Thanks,

Doh - was doing some last minute testing of 400 Bad Request responses for GETs and clearly left it that way when committing - sorry!

It does seem that at least Safari is happy to continue showing the PSystemError diagrams even when returned with a 400 status code, and I'd expect other browsers to do the same. I'll remove the parameter as you suggest.

Using a 400 makes it much easier for programmatic clients to use common http libraries which then notice the error without needing to understand plantuml specific headers.

Thanks for your work. Can you tell how do I get second page with POST? Like what we do in GET:

http://www.plantuml.com/plantuml/svg/0/SoWkIImgAStDuNBAJrBGjLDmpCbCJbMmKYX8J4zLCEJAIoq7iR3A6d4vfEQb0FK20000

http://www.plantuml.com/plantuml/svg/1/SoWkIImgAStDuNBAJrBGjLDmpCbCJbMmKYX8J4zLCEJAIoq7iR3A6d4vfEQb0FK20000

Does POST support compressed diagram? like:

SoWkIImgAStDuNBAJrBGjLDmpCbCJbMmKYX8J4zLCEJAIoq7iR3A6d4vfEQb0FK20000

I see, I have to construct a valid GET URL, like http://www.plantuml.com/plantuml/svg/1/om80, and POST to it to get the right page.

I think it's kind of a bug, when I tries post to http://www.plantuml.com/plantuml/svg/1, I can never get the expected result.

I've never used multiple pages so certainly didn't test it when implementing this feature. Looking at the code though, it appears that so long as a slash is present after the number then the index should be honoured. e.g.

• POST /plantuml/svg/7/asdbfsadfasdfasdf should show page 7 and ignore trailing asdbfsadfasdfasdf
• POST /plantuml/svg/7/ should show page 7
• POST /plantuml/svg/7 should default to page 0, treating 7 as trailing nonsense
• POST /plantuml/svg/ defaults to page 0

This all comes about due to reusing the same URL parsing pattern as used when processing GET requests - there's room for improvement :)

POST does not support compressed diagrams - I assumed compression would be better handled using a filter or proxy implementing HTTP Transfer-Encoding.

@roxspring According to my test, this is the only way to get right result:

• POST /plantuml/svg/7/\w{4,}, like POST /plantuml/svg/1/aaaa

I tested with /plantuml/svg/7/a but failed, so I thought I need to construct the url.

Following are all failed:

• POST /plantuml/svg/1/a
• POST /plantuml/svg/1/aaa
• POST /plantuml/svg/1/

You can quickly reproduce with:

@startuml
!define send(sneder,reciever,message) sneder->reciever : message
send(Alice, Bob, Hello)
newpage
send(Bob,Alice,OK)
@enduml

and:

curl --data-binary @test.wsd http://some.server/png/1/aa > sample.png
curl --data-binary @test.wsd http://some.server/png/1/> sample.png
curl --data-binary @test.wsd http://some.server/png/1/aaaa > sample.png

Only the last command works as expected, get the 'OK' message within the 2nd page.

@roxspring Can you take a look at this issue: #125. Many thanks!