Can HTTP be proxied from the start?

[maryfries]

On BJC4NYC, we are using the HTTP block, but because it doesn't work for most sites, we are having students load a project with this PROXIED HTTP block: But that introduces a whole sideline conversation about what's going on here and why we need to do it this way that isn't otherwise necessary for the curriculum (e.g. AP standards).

Is it possible to re-code the HTTP block so that it passes the URL through a proxy server automatically/behind the scenes?

[brianharvey]

We could, but proxy sites don't last forever. The one we first used has disappeared. The one we're using now belongs to a college freshman. It's easier to react to changes if the URL isn't built in.

[maryfries]

There aren't any stable proxy sites out there?

[brianharvey]

In computer terms, "stable" means "five years."

[maryfries]

Sounds good to me.

[cycomachead]

Also, in general, it's best to not proxy thing unless necessary.

• Proxying is slower than a direct request, and in some cases that slowness causes additional problems
• Some networks can outright detect an ban proxy servers
• Some content breaks when proxied (but I think this is becomming less common).

[maryfries]

I appreciate that it's not ideal, but it's also not ideal to try to explain proxy servers (which aren't part of the course) just to use the HTTP block, which generally doesn't work (in my experience with it) and so has to be proxied. :/

[cycomachead]

Yeah, I think for general purpose Snap!, something separate would be necessary. I know that in the past schools have been very strict about detecting (and blocking) proxy servers.

If there are specific sites we want to use repeatedly, we could also try to talk to the site owners, though that doesn't scale, and doesn't work for projects.

What might not be a bad idea would be to make a library that all teachers can use.

[jmoenig]

So, the reason we need CORS proxies so often isn't because Snap's http block "doesn't work" so often, but because either the providers of the web services people wish to access intentionally decided not to allow http requests from within browsers (and this applies to all scripted http requests, not just to Snap in particular), or because the school network intentionally decided to hide the "berkeley.edu" part of Snap's origin for some security reason that eludes me.

My point is: By the very design of CORS the problem is not on our part, and we should talk to those who are actively blocking web requests. Especially if the problem is that a school network admin decides not to allow http requests I cannot imagine that it's any good if we "hack" that security measure.

Come on, you're UC Berkeley! If not you who else can motivate people?

[cycomachead]

My point is: By the very design of CORS the problem is not on our part, and we should talk to those who are actively blocking web requests.

I agree here, though it is an impossible task to handle all the sites students would want to use. (Also, the default setting of CORS is to allow nothing to pass, and you have to actively allow access so it's not necessarily people trying to be mean.)

As an aside, we should also let the http block be https! Because privacy is better. :)

[jmoenig]

CORS aside I'm open to discussing making the HTTP block more complicated by supporting more options. Alternatively we could offer a little library with additional blocks or with more "MacGyver"-ish multi-functional swiss-army-knife blocks. We should talk about this next week...

I don't want to put a specific server address into the Snap JavaScript sources, though, just because we do have a working solution and there may be "questions" from students about it which "are not part of curriculum" isn't a good reason at all to pretend this is a god-given. Snap is extensible precisely so we can solve issues in Snap itself.

[cycomachead]

CORS aside I'm open to discussing making the HTTP block more complicated by supporting more options. Alternatively we could offer a little library with additional blocks or with more "MacGyver"-ish multi-functional swiss-army-knife blocks. We should talk about this next week...

Yes, and yes! (Personally, I vote for a moderately expanded http block and then a library which handles more cool stuff.)

[brianharvey]

Eventually we'll have the Snapi! version of the http block, but we're not building proxy server names into the code. Load a library.

[nemilya]

Btw there is RaspberryPi and it can be simple http api backend for Snap requests. Just plugin RPi box in local network during masterclass.

For example education lessons https://www.raspberrypi.org/learning/python-web-server-with-flask/

Also It can be simple IoT - led light controlled by Snap) Or any physical computing.

[cycomachead]

Eventually we'll have the Snapi! version of the http block, but we're not building proxy server names into the code. Load a library.

I'm happy to cleanup and submit a PR that creates an HTTP library with a few difference blocks based on JSFunction

[ToonTalk]

I noticed that BJC Unit 4 Lab 1: Website Data, Page 3 uses alloworigin.com which no longer works while http://crossorigin.me is currently working.

[brianharvey]

Yeah. My plan for BJC is to use a proxied http library that tries all the sites we know about until one of them works.