It makes sense for me. I'll think about it and I'll get back to you soon.

This is the proposed syntax for this new feature,
http://www.plantuml.com/plantuml/proxy?idx=0&src=...URL_of_the_markup_file...
The idx (for index) parameter will be optional with a default value of 0 for the first diagram source found.

Note that it's not necessary to encode the URL of the source file. For example, the following URL is valid:
http://www.plantuml.com/plantuml/proxy?src=http://www.server.com/diagram.puml

In the future, a third parameter format could be use to specify the form (png, svg, ...) of the resulting diagram.

Have you any comment ?

Sounds great! Indeed the urlencoding is only necessary when the passed URL contains special characters like ampersands.

You will probably let us know when and where we can try it?

Thinking about this a bit longer... Here's how we could optimize it for the GitHub use case:

Assume from a .md file I added http://www.plantuml.com/github?subdir/file.puml as an image.

The server could then take my referer header, replace "blob" with "raw" in the URL and interpret "subdir/file.puml" as relative path to that.

The idea is to make it a bit easier with relative links instead of absolute ones (shorter). But that should also work when looking at files in branches or in forked repos - you should always get the .puml from the same branch/repo.

Hello,
Don't forget that you can still use URL in your .md file like

http://www.plantuml.com/plantuml/img/Aov9B2hXiYejJbL8pop9A4so1W00

This is just simple as that!

@arnaudroques yes, but that does not allow it to keep .puml around in version control and just render the graphics based on it.

To be coherent with the proxy syntax, it could be
http://www.plantuml.com/plantuml/github?idx=0&src=subdir/file.puml
with idx optional.
But it's very specific to github and if they update their URL scheme, all is broken.

Hi @mpdude
The proxy syntax is deployed and available, you can use it right now.
As an example : http://www.plantuml.com/plantuml/proxy?idx=0&src=https://raw.github.com/maximesinclair/for-testing-purpose/master/twodiaguml.puml

This feature has to be documented on the plantuml website.

Awesome :) I'll try it as soon as possible :)

Yes, it works !

This works with one caveat (a problem with GitHub). The markdown engine renders the

![blah](http://www.plantuml.com/plantuml/proxy?idx=0&src=https://raw.github.com/maximesinclair/for-testing-purpose/master/twodiaguml.puml) 

as an image in the camo.githubusercontent.com web site (image cache). Open this image in a new tab to see an example:

The problem is that this cache won't be updated unless the URL to the image changes. GitHub assumes images to be static, whereas PlantUML images drawn via the proxy are not.

Prior to the proxy service feature, I was using the PlantUML !includeurl URL-to-source.puml (language) feature. A work-around to the GitHub cache problem is to toggle some redundant information in the URL (change the URL without changing the file specification), as explained below.

fuhrmanator/course-activity-planner@45fd5d8

With the proxy service, this workaround might be to add/remove "idx=0&" in the URL.

The official word about Github's CDN caching affecting dynamically generated images is here:
github/markup#224 (comment)

The fix should be changing the cache headers here, where image caching is being forced:
Line 93 at DiagramResponse.java

Yes, by default, PlantUML server sends some Cache-Control/public header for images. This makes sense for text diagram without !include.

We cannot simply remove it for every served image, but we could improve this behaviour:
For example, if we detect some !include directive in the diagram, we could change the header to Cache-Control/no cache.

This is something we have already implemented very basically, see
https://github.com/plantuml/plantuml/blob/master/src/net/sourceforge/plantuml/StringUtils.java#L333

So you can even check now is the following URL gives the right HTTP header
http://www.plantuml.com/plantuml/png/AqijAixCpmC0

How about adding an optional revision tag to the specification?
e.g. : @startuml revision 89

That way, if a diagram

• Includes impredictable changes (e.g. Hosted on Github) AND
  • Includes a revision puml tag and Etag http header (Github does) OR
  • Includes a Last-Revision http header

... that data get attached to the resulting file

• Etag and revision number get concatenated and attached to the image as the new Etag OR
• Last-Revision gets attached to the image

That way Github knows when to grab the new file, files stay as cacheable as possible, and PUML changes get more noticeable (human-readability: any person can check if a diagram has changed in the least)

I have closed duplicate of this issues which I have created with next text:

Given I have public link to text file with uml on gitlab or github, I may paste link into plantuml server and get image.

It would be either reasonable to create issue on github and gitlab to render plantuml inside their web interfaces, like these where done for some other kinds of text - e.g. 2d/3d models.

The option revision tag is a good idea.
We are going to think about it.
We will probably do it slightly differently (that is, providing a special line !pragma revision 89 ), but the result would be the same.
We'll post a message here when http://plantuml.com/plantuml will include this
Thanks for the suggestion!

We have put a new version of the online server http://plantuml.com/plantuml

The code is not published yet, but it will be in few days/weeks.

This version now handles correctly HTTP Headers Cache-Control/Etag/Expires/Last-Modified and is able to send a 304 Not Modified response when the request contains If-Modified-Since/If-None-Match
We did not include any Last-Revision header because we did not find any material about this HTTP header. Is this a standard one ? Any pointer will be welcome.

This way, integration with Github/Gitlab should be improved. Do not hesitate to make feedback about this.
Thanks,

My bad, i was talking about Last-Modified.
Is the revision puml tag still possible?

Yes, it's still possible.
You will have to use something like:

@startuml
!pragma revision 89
...
@enduml

Etag header will be modified when the revision number will be.

according the post Markdown native diagrams with PlantUML | Andreas' Blog, we can set the 'cache' params to be 'no', so when the reffer file is committed, the reffered uml image will be update too.