Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #30022 > unrolled thread

Read binary file

Back to article view | Back to comp.lang.javascript

Contents

  Read binary file Herbert Kleebauer <klee@unibwm.de> - 2016-03-16 23:20 +0100
    Re: Read binary file Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-17 01:04 +0100
      Re: Read binary file Stefan Weiss <krewecherl@gmail.com> - 2016-03-17 02:34 +0100
        Re: Read binary file Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-17 07:56 +0100
      Re: Read binary file Herbert Kleebauer <klee@unibwm.de> - 2016-03-17 08:31 +0100
        Re: Read binary file Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-17 19:10 +0100
          Re: Read binary file Stefan Weiss <krewecherl@gmail.com> - 2016-03-17 19:59 +0100
            Re: Read binary file Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-17 21:43 +0100
              Re: Read binary file Herbert Kleebauer <klee@unibwm.de> - 2016-03-17 22:36 +0100
                Re: Read binary file Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-17 23:15 +0100
                Re: Read binary file Stefan Weiss <krewecherl@gmail.com> - 2016-03-18 00:43 +0100
                  Re: Read binary file Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-18 17:22 +0100
                    Re: Read binary file Herbert Kleebauer <klee@unibwm.de> - 2016-03-18 21:14 +0100
                      Re: Read binary file Matthias Wiehl <mw@kwarg.de> - 2016-03-19 00:02 +0100
                        Re: Read binary file Herbert Kleebauer <klee@unibwm.de> - 2016-03-19 08:48 +0100
                          There is no javascript (was: Read binary file) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-19 13:02 +0100
                            Re: There is no javascript (was: Read binary file) Mark - <nonemail@spamspamapam.net> - 2016-03-19 14:33 +0000
                              Re: There is no javascript (was: Read binary file) Andrew Poulos <ap_prog@hotmail.com> - 2016-03-20 14:30 +1100
                                Re: There is no javascript (was: Read binary file) Mark - <nonemail@spamspamapam.net> - 2016-03-20 13:07 +0000
                            Re: There is no javascript (was: Read binary file) John Harris <niam@jghnorth.org.uk.invalid> - 2016-03-20 10:39 +0000
                            Re: There is no javascript (was: Read binary file) John Harris <niam@jghnorth.org.uk.invalid> - 2016-03-20 11:19 +0000
                              Re: There is no javascript (was: Read binary file) Philip Herlihy <thiswillbounceback@you.com> - 2016-03-21 17:06 +0000
                  Re: Read binary file Scott Sauyet <scott.sauyet@gmail.com> - 2016-03-22 17:18 -0700
                    Re: Read binary file "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-23 10:12 +0100
                      Re: Read binary file John Harris <niam@jghnorth.org.uk.invalid> - 2016-03-23 16:27 +0000
                        Re: Read binary file Herbert Kleebauer <klee@unibwm.de> - 2016-03-24 10:41 +0100
                          Re: Read binary file "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-24 11:14 +0100
                            Re: Read binary file John Harris <niam@jghnorth.org.uk.invalid> - 2016-03-24 11:41 +0000
                              Re: Read binary file "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-24 13:36 +0100
                                Re: Read binary file John Harris <niam@jghnorth.org.uk.invalid> - 2016-03-25 10:07 +0000
                                  Re: Read binary file "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-25 11:28 +0100
                          Re: Read binary file "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-03-24 11:31 +0100
                            Re: Read binary file Herbert Kleebauer <klee@unibwm.de> - 2016-03-24 12:34 +0100
                              Re: Read binary file "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-03-24 17:15 +0100
                          Re: Read binary file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-03-24 11:33 +0000
                        Re: Read binary file "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-24 11:05 +0100
                      Re: Read binary file Scott Sauyet <scott.sauyet@gmail.com> - 2016-03-23 20:16 -0700
                        Re: Read binary file "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-24 10:36 +0100
                          Re: Read binary file "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-24 11:18 +0100
                            Re: Read binary file Scott Sauyet <scott.sauyet@gmail.com> - 2016-03-27 10:22 -0700
                              Re: Read binary file "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-28 00:18 +0200
                                Re: Read binary file Scott Sauyet <scott.sauyet@gmail.com> - 2016-03-28 05:35 -0700
                                  Re: Read binary file "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-03-29 00:53 +0200
    Re: Read binary file Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-17 02:23 +0100
    Re: Read binary file Herbert Kleebauer <klee@unibwm.de> - 2016-03-17 08:42 +0100
    Re: Read binary file Dr J R Stockton <reply1600@merlyn.demon.co.uk.invalid> - 2016-03-20 22:03 +0000

Page 1 of 3  [1] 2 3  Next page →

#30022 — Read binary file

There is a picture (1.jpg) on web server A and I want to make
a modified version available using a web server B. Because
of copyright I can't just copy the picture, modify it and
store it on server B. Instead a html file (test.htm) and
a data file which describes how the picture has to be
modified (diff.dat) is stored on server B. When a user
loads the html file into his browsers, the javascript code
loads the original picture from server A and the modification
file from server B, changes the picture and displays it.

I'm not familiar with javascript, but with help of Google
I hacked together a few lines of code. But it only works if
all three files are on the same server:

http://ikomi.de/test/test.htm
http://ikomi.de/test/1.jpg
http://ikomi.de/test/diff.dat


If the picture is on a different server, there seems to be
an access violation. How can I avoid this violation or in
which other way can I read a binary file from a different
web server into a javascript array.



<html><head><title>jpg</title>
<script type="text/javascript">

function load_binary_resource(url) {
  var req = new XMLHttpRequest();
  req.open('GET', url, false);
  req.overrideMimeType('text\/plain; charset=x-user-defined');
  req.send(null);
  if (req.status != 200) return '';
  return req.responseText;}

var original = load_binary_resource("http://ikomi.de/test/1.jpg");
var diff = load_binary_resource("http://ikomi.de/test/diff.dat");

data='';
for (i = 0; i < diff.length; i++) {
  m=i%original.length;
  data += String.fromCharCode((original.charCodeAt(m)^diff.charCodeAt(i))&0xff);}

document.write('<img src="data:image/jpg;base64,');
document.write(btoa(data));
document.write('">');

</script></head><body></body></html>

[toc] | [next] | [standalone]

#30023

Herbert Kleebauer wrote:

> There is a picture (1.jpg) on web server A and I want to make
> a modified version available using a web server B. Because
> of copyright I can't just copy the picture, modify it and
> store it on server B. Instead a html file (test.htm) and
> a data file which describes how the picture has to be
> modified (diff.dat) is stored on server B. When a user
> loads the html file into his browsers, the javascript code
> loads the original picture from server A and the modification
> file from server B, changes the picture and displays it.

Your logic is flawed.  Either there it is a copyright violation to create a 
modified version of the original, or there is not.  If there is a copyright 
violation, then no matter how you create the modified version, the issue 
remains: publishing the modified version would be a copyright violation.
If there is no copyright violation with copying and modifying the original, 
then there is no need to go to great lengths to do the modification.

I suggest that you at least read <https://en.wikipedia.org/wiki/Copyright> 
to get an idea if the publication of the modified version would constitute a 
copyright violation in the first place (I would suggest consulting a 
copyright lawyer as well depending on the presumed value of the original 
work and the fees to be expected from you or the organization you are 
working for in case of a possible copyright violation).
 
> I'm not familiar with javascript,

There is no javascript.

> but with help of Google
> I hacked together a few lines of code. But it only works if
> all three files are on the same server:
> 
> http://ikomi.de/test/test.htm
> http://ikomi.de/test/1.jpg
> http://ikomi.de/test/diff.dat
> 
> 
> If the picture is on a different server, there seems to be
> an access violation. How can I avoid this violation

You cannot.  The whole point of the Same Origin Policy is to prevent people 
from doing things like what you attempted.

> or in which other way can I read a binary file from a different
> web server into a javascript array.

I know how (it is actually trivial if you think it through), but until I am 
certain that you are not attempting a copyright violation through the back 
door, I will not say.
 
IANAL.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#30026

On 03/17/2016 01:04, Thomas 'PointedEars' Lahn wrote:
> Herbert Kleebauer wrote:
>> If the picture is on a different server, there seems to be
>> an access violation. How can I avoid this violation
> 
> You cannot. The whole point of the Same Origin Policy is to prevent people
> from doing things like what you attempted.

The same-origin policy is a security feature; it has nothing to do with
copyright.

>> or in which other way can I read a binary file from a different
>> web server into a javascript array.
> 
> I know how (it is actually trivial if you think it through), but until I am 
> certain that you are not attempting a copyright violation through the back 
> door, I will not say.

I'm curious. Without CORS, I can't think of a way to get a byte array
from an image on a different server. XHR won't work, and neither will
image → canvas → data. What's the trivial solution?


- stefan

[toc] | [prev] | [next] | [standalone]

#30027

Stefan Weiss wrote:

> On 03/17/2016 01:04, Thomas 'PointedEars' Lahn wrote:
>> Herbert Kleebauer wrote:
>>> If the picture is on a different server, there seems to be
>>> an access violation. How can I avoid this violation
>> 
>> You cannot. The whole point of the Same Origin Policy is to prevent
>> people from doing things like what you attempted.
> 
> The same-origin policy is a security feature; it has nothing to do with
> copyright.

Learn to read.

>>> or in which other way can I read a binary file from a different
>>> web server into a javascript array.
>> 
>> I know how (it is actually trivial if you think it through), but until I
>> am certain that you are not attempting a copyright violation through the
>> back door, I will not say.
> 
> I'm curious. Without CORS, I can't think of a way to get a byte array
> from an image on a different server. XHR won't work, and neither will
> image → canvas → data. What's the trivial solution?

Nice try.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#30028

On 17.03.2016 01:04, Thomas 'PointedEars' Lahn wrote:
> Herbert Kleebauer wrote:
> 
>> There is a picture (1.jpg) on web server A and I want to make
>> a modified version available using a web server B. Because
>> of copyright I can't just copy the picture, modify it and
>> store it on server B. Instead a html file (test.htm) and
>> a data file which describes how the picture has to be
>> modified (diff.dat) is stored on server B. When a user
>> loads the html file into his browsers, the javascript code
>> loads the original picture from server A and the modification
>> file from server B, changes the picture and displays it.
> 
> Your logic is flawed.  Either there it is a copyright violation to create a 
> modified version of the original, or there is not.  If there is a copyright 
> violation, then no matter how you create the modified version, the issue 
> remains: publishing the modified version would be a copyright violation.

You didn't understand the scenario. Server B only provides the
information where to find the original picture and how to
modify it. Server B never downloads a version of the picture
nor stores a modified version of it. It is the web user on
his own PC who downloads this information and the original
picture and does the modification on-the-fly (no version of
the modified picture is written to the hard disk on the
users PC). Suppose the Server B provides this information:
"download the picture http://ikomi.de/test/1.jpg and
increase brightness by 10% and decrease contrast by 5%".
Why does this violate any copyright?

Instead I could provide a batch script on Server B, which,
when executed on the users PC, will use wget to download the
picture and then use a scriptable image editor (like ImageMagicks
convert.exe) to do the modification. But it would be much
simpler to just use a web browser.

>> I'm not familiar with javascript,
> 
> There is no javascript.

???????????


>> or in which other way can I read a binary file from a different
>> web server into a javascript array.
> 
> I know how (it is actually trivial if you think it through), 

I'm not even sure what the problem is. Does the browser refuse
to read data from a different server than the html file was read
for security reasons or does server A refuse to deliver the
picture because of a referer header.

[toc] | [prev] | [next] | [standalone]

#30036

Herbert Kleebauer wrote:

> On 17.03.2016 01:04, Thomas 'PointedEars' Lahn wrote:
>> Herbert Kleebauer wrote:
>>> There is a picture (1.jpg) on web server A and I want to make
>>> a modified version available using a web server B. Because
                                                       ^^^^^^^
>>> of copyright I can't just copy the picture, modify it and
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> store it on server B. Instead a html file (test.htm) and
    ^^^^^^^^^^^^^^^^^^^^^
>>> a data file which describes how the picture has to be
>>> modified (diff.dat) is stored on server B. When a user
>>> loads the html file into his browsers, the javascript code
>>> loads the original picture from server A and the modification
>>> file from server B, changes the picture and displays it.
>> 
>> Your logic is flawed.  Either there it is a copyright violation to create
>> a modified version of the original, or there is not.  If there is a
>> copyright violation, then no matter how you create the modified version,
>> the issue remains: publishing the modified version would be a copyright
>> violation.
> 
> You didn't understand the scenario.

ACK, your claim confused me (see below), therefore I misread.

> […]
> Suppose the Server B provides this information:
> "download the picture http://ikomi.de/test/1.jpg and
> increase brightness by 10% and decrease contrast by 5%".
> Why does this violate any copyright?

Of itself it does not.  You were the one claiming that it would.  However, 
whether the whole use-case could constitute a copyright violation depends
on the extent of the modification and who has access to the modified 
version.
 
> Instead I could provide a batch script on Server B, which,
> when executed on the users PC, will use wget to download the
> picture and then use a scriptable image editor (like ImageMagicks
> convert.exe) to do the modification. But it would be much
> simpler to just use a web browser.

The Canvas API appears to be what you are looking for:

<https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Pixel_manipulation_with_canvas>

(CORS obviously cannot help you there as you do not control the server of 
the original work.)

>>> I'm not familiar with javascript,
>> There is no javascript.
> 
> ???????????

See the reference to the “ES Matrix” in my signature.

>>> or in which other way can I read a binary file from a different
>>> web server into a javascript array.
>> I know how (it is actually trivial if you think it through),

(JFTR: Canvas is not what I meant with this.  I had not thought of that 
possibility at the time.)
 
> I'm not even sure what the problem is. Does the browser refuse
> to read data from a different server than the html file was read
> for security reasons or does server A refuse to deliver the
> picture because of a referer header.

No.  STFW for “Same Origin Policy”.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#30037

Thomas 'PointedEars' Lahn wrote:
> Herbert Kleebauer wrote:
>> Suppose the Server B provides this information:
>> "download the picture http://ikomi.de/test/1.jpg and
>> increase brightness by 10% and decrease contrast by 5%".
[...]

> The Canvas API appears to be what you are looking for:
> 
> <https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Pixel_manipulation_with_canvas>
> 
> (CORS obviously cannot help you there as you do not control the server of 
> the original work.)

As I mentioned earlier, this does not work cross-origin without CORS.
Adding image data from server A to the canvas will taint it, preventing
data extraction and manipulation.

>>> I know how (it is actually trivial if you think it through),
> 
> (JFTR: Canvas is not what I meant with this.  I had not thought of that 
> possibility at the time.)

So, now that the copyright situation has been explained, what's the
trivial solution?


- stefan

[toc] | [prev] | [next] | [standalone]

#30039

Stefan Weiss wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Herbert Kleebauer wrote:
>>> Suppose the Server B provides this information:
>>> "download the picture http://ikomi.de/test/1.jpg and
>>> increase brightness by 10% and decrease contrast by 5%".
> [...]
> 
>> The Canvas API appears to be what you are looking for:
>> 
>> <https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API/Tutorial/Pixel_manipulation_with_canvas>
>> 
>> (CORS obviously cannot help you there as you do not control the server of
>> the original work.)
> 
> As I mentioned earlier, this does not work cross-origin without CORS.

Indeed.  The Canvas tutorial should be updated with that information.

> Adding image data from server A to the canvas will taint it, preventing
> data extraction and manipulation.

Yes, but:

The Same Origin Policy (SOP) does not depend on the server; it depends on 
protocol and domain names, and port numbers.

Therefore:

> >>> I know how (it is actually trivial if you think it through),
> > (JFTR: Canvas is not what I meant with this.  I had not thought of that 
> > possibility at the time.)
> 
> So, now that the copyright situation has been explained, what's the
> trivial solution?

Transparent HTTP proxying with mod_rewrite, mod_proxy, mod_proxy_http & 
friends.  If the Web browser does not know that a resource has a different 
origin, the SOP does not apply.  WFM with Apache/2.4.18 (Debian) in Chromium 
“46.0.2490.71 Built on 8.2, running on Debian stretch/sid (64-bit)” (which 
would without proxying and CORS block access precisely as you described).

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#30040

On 17.03.2016 21:43, Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:

>> So, now that the copyright situation has been explained, what's the
>> trivial solution?

> Transparent HTTP proxying with mod_rewrite, mod_proxy, mod_proxy_http & 

That's neither a trivial solution nor a solution at all. The user only
gets the the url of the original picture and the url of the modifcation
file. The user doesn't use a proxy. I can understand why a server doesn't
deliver the picture if it doesn't like a referer header, but I can't
understand the restrictions by the browser. I see it as a fundamental
function to read any accessible file on any web server into a javascript
array (even by removing the referer header if necessary).


>>> There is no javascript.
>> ???????????
> See the reference to the “ES Matrix” in my signature.

<html><head><title>jpg</title>
<script type="text/javascript">
:
:
</script></head><body></body></html>

It is declared as javascript and therefore it is by definition javascript.
Whether it is processed by a javascript, JavaScript or a ECMAScript
interpreter doesn't matter, by definition the code itself is javascript
code.

[toc] | [prev] | [next] | [standalone]

#30041

Herbert Kleebauer wrote:

> On 17.03.2016 21:43, Thomas 'PointedEars' Lahn wrote:
>> Stefan Weiss wrote:
>>> So, now that the copyright situation has been explained, what's the
>>> trivial solution?
> 
>> Transparent HTTP proxying with mod_rewrite, mod_proxy, mod_proxy_http &
> 
> That's neither a trivial solution

It was trivial to me (I did the configuration – essentially one line in an 
.htaccess file – of my local server this evening in less than one hour), 
although I have to admit that I had to look a few things up as I did not 
remember them exactly (Stack Overflow was very helpful there as other people 
faced the same, eventually trivially-to-solve, problems as I).

> nor a solution at all.

Have you even tried it?

> The user only gets the the url of the original picture and the url of the
> modifcation file. The user doesn't use a proxy.

They do not have to.  As you are reading superficially, you are jumping to 
conclusions.

> I can understand why a server doesn't deliver the picture if it doesn't
> like a referer header,

That is the only catch with the solution I suggested (and *tried* 
*successfully*) that I can think of.  If the Referer [sic!] header field 
value is checked by the original host, then either the user must disable 
transmitting that header field in their browser, or the forward proxy must 
be configured not to forward that header field (assuming that the original 
host is not unwisely configured to depend on the transmission of that field, 
since it is optional according to HTTP).  It may also be necessary for the 
forward proxy to pretend to be a (certain) Web browser by sending 
corresponding header fields (at least, “User-Agent”).

> but I can't understand the restrictions by the browser. I see it as a 
> fundamental function to read any accessible file on any web server into a
> javascript array (even by removing the referer header if necessary).

You have not even attempted to google “Same Origin Policy” yet, have you?

It is futile to complain about this (here).  Browsers work the way that they 
do.  All you can do is make the best of it since not all of those that are 
used are free software.

>>>> There is no javascript.
>>> ???????????
>> See the reference to the “ES Matrix” in my signature.
> 
> <html><head><title>jpg</title>
> <script type="text/javascript">
> :
> :
> </script></head><body></body></html>

When I said “See the reference …”, I meant that you should *follow*
the reference and *read* the explanations in the referred document.

I did not mean that you should post code in order to support your 
misconceptions.

> It is declared as javascript

It is not.

> and therefore it is by definition javascript.

Ex falso quodlibet.

> Whether it is processed by a javascript, JavaScript or a ECMAScript
> interpreter doesn't matter, by definition the code itself is javascript
> code.

Such a nonsense, it is not even wrong.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#30042

Herbert Kleebauer wrote:
> On 17.03.2016 21:43, Thomas 'PointedEars' Lahn wrote:
>> Stefan Weiss wrote:
>>> So, now that the copyright situation has been explained, what's the
>>> trivial solution?
> 
>> Transparent HTTP proxying with mod_rewrite, mod_proxy, mod_proxy_http & 
> 
> That's neither a trivial solution nor a solution at all.

Right, that doesn't really solve the problem. It makes server B fetch
the image from server A, which is what you wanted to avoid in the first
place.

Proxying (or even caching) foreign content works, but it also changes
the setup and possibly the legal situation. I'm not a lawyer, so I can't
comment on how this would affect your project.

And no, I wouldn't see that as a "trivial" solution either.

> The user only gets the the url of the original picture and the url of
> the modifcation file. The user doesn't use a proxy.

The idea was that your server would act as a proxy for the remote
original images. From the POV of the user (and the browser), the images
would appear to originate from your server, and the same-origin policy
would not pose a problem.

> I can understand why a server doesn't deliver the picture if it
> doesn't like a referer header, but I can't understand the
> restrictions by the browser. I see it as a fundamental function to
> read any accessible file on any web server into a javascript array
> (even by removing the referer header if necessary).

It's not JavaScript that imposes these restrictions, it's the
environment (the browser). Browsers had to adopt this policy to protect
users from scripts on malicious websites: without it, any script on any
site would have a form of remote control over the browser - including
requesting and processing data from another site you're currently logged
into, or posting to the site with your credentials (cookies).
(By the way, scripts can still send GET/POST requests to off-origin
sites, but they typically cannot access the response.)

The unfortunate side-effect of this protection is that some legitimate
requests to off-origin sources are now also blocked by default.

I don't see any clean way around this in your case, unless you can
convince the original image hosts to opt in to CORS. Other workarounds
include the proxying described by TL, browser extensions, and user
scripts (for example, GreaseMonkey scripts can use GM_xmlhttpRequest()
which isn't restricted to the same origin).

>>>> There is no javascript.
>>> ???????????
>> See the reference to the “ES Matrix” in my signature.
> 
> <html><head><title>jpg</title>
> <script type="text/javascript">
[...]
> It is declared as javascript and therefore it is by definition javascript.
> Whether it is processed by a javascript, JavaScript or a ECMAScript
> interpreter doesn't matter, by definition the code itself is javascript
> code.

Please just ignore the "there is no javascript" comment.
Thomas Lahn has a stick up his ass about the spelling of JavaScript;
this has caused endless flames and debates over the years (see
<https://goo.gl/W4CQaX> if you're feeling masochistic). The less
attention we pay to it, the better.


- stefan

[toc] | [prev] | [next] | [standalone]

#30049

Stefan Weiss wrote:

> Herbert Kleebauer wrote:
>> On 17.03.2016 21:43, Thomas 'PointedEars' Lahn wrote:
>>> Stefan Weiss wrote:
>>>> So, now that the copyright situation has been explained, what's the
>>>> trivial solution?
>>> Transparent HTTP proxying with mod_rewrite, mod_proxy, mod_proxy_http &
>> That's neither a trivial solution nor a solution at all.
> 
> Right, that doesn't really solve the problem. It makes server B fetch
> the image from server A, which is what you wanted to avoid in the first
> place.

Wishful thinking.  He did _not_ say that.  He said:

| Because of copyright I can't just copy the picture, modify it and
| store it on server B. […]

> Proxying (or even caching) foreign content works,

Proxying is different from copying, and from caching.

> but it also changes the setup

A change of setup is required in any case.

> And no, I wouldn't see that as a "trivial" solution either.

Argument from ignorance.  As I said, in the best case it is basically one 
line that needs to be added to an .htaccess file:

<https://httpd.apache.org/docs/current/rewrite/flags.html#flag_p>

(Usually you would not want to forward all requests, so you would also 
prepend a RewriteCond.)

> and possibly the legal situation.

Yes, it could.

> I'm not a lawyer, so I can't comment on how this would affect your
> project.

I am not a lawyer either, and not only have I said so, I have also not 
implied anything about the legal situation with this solution yet.  However, 
since transparent proxying of *all* resources is standard practice (several 
ISPs do it in order to increase the quality of service they render to their 
customers), I find it difficult to believe that this solution, with this 
use-case, could constitute a copyright violation.

>>>>> There is no javascript.
>>>> ???????????
>>> See the reference to the “ES Matrix” in my signature.
>> 
>> <html><head><title>jpg</title>
>> <script type="text/javascript">
> [...]
>> It is declared as javascript and therefore it is by definition
>> javascript. Whether it is processed by a javascript, JavaScript or a
>> ECMAScript interpreter doesn't matter, by definition the code itself is
>> javascript code.
> 
> Please just ignore the "there is no javascript" comment.

… so that your silence of not-knowing is not disturbed.  Bad advice.

> Thomas Lahn has a stick up his ass about the spelling of JavaScript;
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That is _not_ what this is about.  Not only have I explicitly written that 
numerous times, but also you *know* it (how many times have I told you this 
now?  Because I lost count).  Continuing to spread such misinformation marks 
you as a troll.

> this has caused endless flames

_Not_ started or continued by *me*.  You are confusing cause and effect 
here.  It is the failure of the people who fail to come up with sound 
arguments, and attack the person instead of the issue (which at the least 
from now on includes you, see the marking above), that cause flamewars to 
ensue.  People like *you* are the cause of the noise.  *I* have done my 
homework a long time ago, and I am continuing to do it; they (which includes 
you) are not even willing *to look* at the detailed evidence that I 
present(ed).

> and debates over the years

And that is a *Good* Thing.  It is what is *supposed to happen here*, in 
this Usenet *discussion* group.  Common misconceptions of the “javascript” 
sort *need* to be discussed and clarified if we should have any hope at 
gaining true knowledge.  If necessary, those discussions need to take place 
over and over again until *someone* finally gets the point of the argument 
and spreads the word (it is acceptable for me to say that a few people 
already have).  You, on the other hand, are obviously light-years away from 
understanding the misconception that you have acquired there; you are still, 
even after so many years, in that regard a blind man.  That in itself would 
not be a major problem, but you profess to teach novices, with which you 
become a blind leading the blind.  Herbert should be aware of who he puts 
his trust in, lest it not be misdirected and misused.

> (see <https://goo.gl/W4CQaX> if you're feeling masochistic).

… or less foolish than you.

> The less attention we pay to it, the better.

Wrong.  Ignoring or killing the messenger, continuing to live in blissful 
ignorance, does not make the message and the problem reported in it go away.
The less attention is paid to the inherent differences between ECMAScript 
implementations, and between those programming languages and the 
implementations of language-independent APIs (like the DOM) – which is what 
this is *actually* all about –, the less compatible and the more error-prone 
programs written in those programming languages are going to be.  The record 
shows.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#30050

On 18.03.2016 17:22, Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:

>> Right, that doesn't really solve the problem. It makes server B fetch
>> the image from server A, which is what you wanted to avoid in the first
>> place.
> 
> Wishful thinking.  He did _not_ say that.  He said:
> 
> | Because of copyright I can't just copy the picture, modify it and
> | store it on server B. […]

Where is the difference?


> Proxying is different from copying, and from caching.

For me a proxy is a server which collects the HTTP requests
from a client, checks if a local copy is available
and if not fetches it from the original server. This is
transparent for the client because he always sends
the original URL. In this case this would mean, the
client sends a request for http://serverA/1.jpg.

But if I understand you correct, you are suggesting to
send a request for http://serverB/1.jpg and serverB
changes this to http://serverA/1.jpg and forwards it
to a local proxy. But the final effect is, that there
is a 1.jpg on server B which can be accessed by
http://serverB/1.jpg and this surely is a copyright
violation. It doesn't matter whether this jpg is stored
permanent in the file system, temporary in the proxy cache
or just forwarded from serverA.


>>>>>> There is no javascript.
>>>>> ???????????
>>>> See the reference to the “ES Matrix” in my signature.

I don't understand your problems with "javascript"
(http://pointedears.de/es-matrix just gives a "Forbidden").

JavaScript was introduced by and is a trademark of Netscape
(now Oracle). Later the Standard ECMA-262 was created and
there are many implementations of this standard (including
JavaScript). The commonly used name for all this implementation
is "javascript". Therefore normally is written:


>>> <html><head><title>jpg</title>
>>> <script type="text/javascript">

and not:

>>> <script type="text/JavaScript">

[toc] | [prev] | [next] | [standalone]

#30051

Herbert Kleebauer <klee@unibwm.de> writes:

> JavaScript was introduced by and is a trademark of Netscape
> (now Oracle). Later the Standard ECMA-262 was created and
> there are many implementations of this standard (including
> JavaScript). The commonly used name for all this implementation
> is "javascript". Therefore normally is written:
>
>>>> <html><head><title>jpg</title>
>>>> <script type="text/javascript">
>
> and not:
>
>>>> <script type="text/JavaScript">

No, that is because MIME types are lowercase by convention (and
case-insensitive, see RFC 2045).

[toc] | [prev] | [next] | [standalone]

#30053

On 19.03.2016 00:02, Matthias Wiehl wrote:
> Herbert Kleebauer <klee@unibwm.de> writes:
> 
>> JavaScript was introduced by and is a trademark of Netscape
>> (now Oracle). Later the Standard ECMA-262 was created and
>> there are many implementations of this standard (including
>> JavaScript). The commonly used name for all this implementation
>> is "javascript". Therefore normally is written:
>>
>>>>> <html><head><title>jpg</title>
>>>>> <script type="text/javascript">
>>
>> and not:
>>
>>>>> <script type="text/JavaScript">
> 
> No, that is because MIME types are lowercase by convention (and
> case-insensitive, see RFC 2045).

They are case insensitive and therefore there is no need for
a convention (do you have any link to this convention?). But
there is a good reason to not use "JavaScript" because this
would suggest Netscapes implementation of ECMA-262 and not
an arbitrary implementation.

[toc] | [prev] | [next] | [standalone]

#30054 — There is no javascript (was: Read binary file)

Herbert Kleebauer wrote:

> On 19.03.2016 00:02, Matthias Wiehl wrote:
>> Herbert Kleebauer <klee@unibwm.de> writes:
>>> JavaScript was introduced by and is a trademark of Netscape
>>> (now Oracle).

“JavaScript” was from 1996 to 2010 inclusive, by license agreement between 
Netscape Communications Corporation and Sun Microsystems, Inc. (Sun) in 
December 1995, a trademark of _Sun_, which had been acquired by Oracle 
Corporation (Oracle) in 2010, through which “JavaScript” has become a 
trademark of Oracle. [0a]  (The legal successor to Netscape is not Oracle
as your statement could be misunderstood to mean, but AOL; see below.)

>>> Later the Standard ECMA-262 was created and there are many
>>> implementations of this standard

Correct.  But note that “This ECMA Standard is based on several originating 
technologies, the most well known being JavaScript™ (Netscape
Communications) and JScript™ (Microsoft Corporation).” [0b]

>>> (including JavaScript).

But even “JavaScript” does not in general refer to a single implementation 
of ECMAScript since more than a decade, and the implementation*s* that it 
would refer to differ from one another in their feature set (as shown by my 
research).

>>> The commonly used name for all this implementation is "javascript". 

Wishful thinking.  Instead, it is primarily used by people, most of them 
laymen, who do not know what they are talking about when using it (as shown 
by the very posting that I am just replying to), which inherently 
constitutes the majority of the people using it (since nobody can know about 
everything in detail, there are always more people who do not know about 
something than people who do).

But this is a technical newsgroup; we must aspire here to be *correct* and 
*precise* instead of catering to the misconceptions and ambiguity of the 
general public.  For it is never the general public that defines the proper 
meaning of technical terms, but the people employing the corresponding 
technology professionally.  And should there be a *well-founded* 
disagreement about terminology among professionals, then it is not the place 
of the general public to decide which terminology is the correct one; it is 
not the place of the layman to tell the expert how they should name their 
things.  You do not (reasonably) try to tell a Chinese how to pronounce 
Chinese properly either.

>>> Therefore normally is written:
>>>
>>>>>> <html><head><title>jpg</title>
>>>>>> <script type="text/javascript">
>>>
>>> and not:
>>>
>>>>>> <script type="text/JavaScript">
>> 
>> No, that is because MIME types are lowercase by convention (and
>> case-insensitive, see RFC 2045).
> 
> They are case insensitive and therefore there is no need for
> a convention

Not even wrong.  It is the convention/standard that *defines* MIME media 
types as case-insensitive (“not case sensitive”), not the other way around.

> (do you have any link to this convention?).

Inherently, there are no links here; this is a plain-text medium.  You might 
mean a URI which your NetNews client may be able to turn into a hyperlink.

He just gave you the proper reference: RFC 2045 (“Multipurpose Internet Mail 
Extensions (MIME) Part One: Format of Internet Message Bodies”).  I can add 
that the definition can be found in the section on the “Content-Type” header 
field.  Look it up.

> But there is a good reason to not use "JavaScript" because this
> would suggest Netscapes implementation of ECMA-262 and not
> an arbitrary implementation.

Only to the underinformed (who have read neither the ECMAScript Support 
Matrix nor the scientific work referred therein¹):

First of all, Netscape Communications (Corporation) as an independent 
company does not exist anymore.  It stopped being a vendor of programming 
languages in 1998 (CE), of Internet application suites in 2002 (after the 
acquisition by America Online, Inc.), and of Web browsers in 2008 (on March 
1st, when support for all Netscape browser and client products was 
terminated by AOL²). [1a]

Its legacy is carried on by the Mozilla Organization and contributors 
(Mozilla) since 1998 and the Mozilla Corporation since 2005.  Mozilla’s 
ECMAScript implementation, Mozilla JavaScript (first release: version 1.5 in 
2000), has both regarding its source code and its feature set little to do 
with the last released versions of Netscape JavaScript (1.3 in 1998, and 1.4 
in 1999). [2]

Second, contrary to common belief, using “javascript” conveys exactly 
*nothing* to the reader about the referred implementation of ECMAScript;
it does not even convey anything to the reader about the author’s intention 
to refer to implementations of ECMAScript.  Both are making it impossible
to assign truth values to any statement made about “javascript” as not
all implementations are conforming.  Instead, it conveys the misconception 
(intentionally or not) that there would be a single programming language, 
“javascript”, that also encompasses all the features actually provided by 
language-independent APIs that can also be used with implementations of 
ECMAScript.

Third, there are now several implementations of ECMAScript, including some 
distributed wider than Mozilla JavaScript (as seen worldwide), by vendors 
other than Mozilla, whose names contain “JavaScript” (in possible trademark 
violation) without being compatible to any version of either Netscape 
JavaScript or Mozilla JavaScript (most notably, Google V8 JavaScript [3]).  
So even using just “JavaScript” leaves ambiguity, exhibiting the same 
problems as “Javascript” or “javascript”, only to a lesser extent.

  [IOW, the charter and tagline of this newsgroup are more than a decade
   out of date, and do not reflect what is being rightfully discussed here:
   ECMAScript and its implementations, and applications thereof, unless
   there is a more specific newsgroup (see the FAQ).  (Neither does the name
   of this newsgroup reflect what is being discussed here, so any arguments
   that it should be “javascript” because of “comp.lang.javascript” are
   utterly ridiculous, also because *all* Usenet newsgroup names are
   lowercase by convention.)]

__________
¹  My experiments with transparent proxying because of this thread caused 
   temporary denial of access to my Web site.  Also, due to migration
   to Git, my thesis had not been available online since at least
   2016-03-08.  Sorry for the inconvenience; it is fixed now.
   
²  I just tried to access <http://netscape.com/> and 
   <http://www.netscape.com/>, and was redirected to <http://www.aol.com//>
   (sic!).  So it appears that Netscape does not even exist as an Internet
   service anymore, which had not been the case yet a few months ago when
   I had been redirected to <http://netscape.aol.com/> instead. [1b]

[0a] <http://www.infoworld.com/article/2653798/application-development/javascript-creator-ponders-past--future.html>
[0b] <http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%201st%20edition,%20June%201997.pdf>
[1a] <https://en.wikipedia.org/wiki/Netscape>
[1b] 
<http://wayback.archive.org/web/20160229003526/http://www.netscape.com/>
[2] <https://developer.mozilla.org/de/docs/Web/JavaScript>
[3] <http://gs.statcounter.com/#all-browser-ww-monthly-201603-201603-bar>

    (Chrome: 47.26 %; Firefox: 8.67 %)

    <http://gs.statcounter.com/#all-browser-ww-monthly-201603-201603-map>

    (Considering all devices, Chrome/Chromium, therefore Google V8 
     JavaScript, dominates the Americas, Europe, most of Asia, and
     Australia; Firefox, therefore Mozilla JavaScript, is only dominant in 
     Greenland and Eritrea, Opera dominates most of Africa; UC Browser
     dominates Mali, India, and most of Oceania.  The situation is only
     slightly better for Firefox if you consider only the desktop, where it
     still also dominates Germany, the minority of Africa, Iran, Bangladesh,
     and Myanmar.  Also note that these considerations do not include V8
     JavaScript with Node.js outside the Web browser.)
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#30055 — Re: There is no javascript (was: Read binary file)

>> (do you have any link to this convention?).
>> 
> Inherently, there are no links here; this is a plain-text medium. You
> might mean a URI which your NetNews client may be able to turn into a
> hyperlink.

Wow; why such disdain for a fellow human? 

No need to answer. It would only be a pedantic answer coupled with justifications 
for incivility.

[toc] | [prev] | [next] | [standalone]

#30058 — Re: There is no javascript (was: Read binary file)

On 20/03/2016 1:33 AM, Mark - wrote:
>
>>> (do you have any link to this convention?).
>>>
>> Inherently, there are no links here; this is a plain-text medium. You
>> might mean a URI which your NetNews client may be able to turn into a
>> hyperlink.
>
> Wow; why such disdain for a fellow human?

It doesn't cease to surprise me how people (you, in this example) are 
more than willingly to look for anything at all, no matter how tenuous, 
with which to support some hypothesis as to the emotional state of 
someone whom they have never, and probably will never, meet

> No need to answer. It would only be a pedantic answer coupled with
> justifications for incivility.

BTW how do you justify your lack of civility?

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#30061 — Re: There is no javascript (was: Read binary file)

> BTW how do you justify your lack of civility?

You are confused. 

[toc] | [prev] | [next] | [standalone]

#30059 — Re: There is no javascript (was: Read binary file)

On Sat, 19 Mar 2016 13:02:59 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

  <snip>
>But this is a technical newsgroup; we must aspire here to be *correct* and 
>*precise* instead of catering to the misconceptions and ambiguity of the 
>general public.
  <snip>

Interesting.

We must remember to quote this next time Thomas says something
ill-informed about sets.

  John

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web