H2S88: How to send an HTTP-req, in PHP:

Hu-red: 🔑 A GET request is copy pasting the URL of a Google doc into the body of the doc.

<?php
$opts = array(
  'http'=>array(
    'method'=>"GET",
    'header'=>"Accept-language: en\r\n" .
              "Cookie: foo=bar\r\n"
  )
);

$context = stream_context_create($opts);

/* Sends an http request to www.example.com
   with additional headers shown above */
$fp = fopen('http://www.example.com', 'r', false, $context);
fpassthru($fp);
fclose($fp);
?>

Code via <php.net><a-r>: Hu: This code also tell us that the Web.Sockets-server needs to be located in a specific file, since fopen is a function that reads files #

H3S1: Web.Sockets-agonostic,HTTP.ping:

Hu: We need 2 files: a client side, that sends an HTTP-request. These are asymmetrical, by design. A second file, which contains a response. The latter fail, by our understanding<WP.MIC-H2S81,H2.H4S6>: should be specified in the GET row of the request. We need to confirm, on the client-side, that the request was “pinged” back. Let’s test this with an absoluteURI to start, and then experiment with parameter changes.

H4S1: Pear-PHP for HTTP_request:

<Pear-PHP>: PEAR is a framework and distribution system for reusable PHP components. PEAR is short for “PHP Extension and Application Repository” and is pronounced just like the fruit. The purpose of PEAR is to provide:

  • A structured library of open-source code for PHP users
  • A system for code distribution and package maintenance
  • A standard style for code written in PHP, specified here
  • The PHP Extension Community Library (PECL), see more below
  • A web site, mailing lists and download mirrors to support the PHP/PEAR community

Read more at <WP.MIC-H2S76> The base installation that comes with the PHP distribution contains all the stuff that is needed to run the PEAR installation tools etc. If you have a recent installation of PHP, you can relax: The PEAR base installation is already there. Hu: I confirmed in Notepad++ that typing the PEAR-func http_request turned blue<tips.and-tricks>so by this, we know that we need not install, or add complexity. The package provides an easy way to perform HTTP requests. It supports GET/POST/HEAD/TRACE/PUT/DELETE, Basic authentication, Proxy, Proxy Authentication, SSL, file uploads etc. Because of the above mentioned features HTTP_Request makes it possible to mimic big parts of web browsers such as the widely-known Mozilla browser in PHP applications. Possible application areas are: 1) Checking the validity of WWW links with the help of getResponseCode. 2) Grabbing remote | web pages and parsing the result etc. Hu: 11/3/22: Hard to install, multiple red-flags in repo, of auxiliary features that have not had support in 10+ years, difficulty generating response, so I’ll have a one.sided-dependency. Bailing for now. 🥴

H3S2: Generating a request string/array, hard-coded:

Ref:<WP.MIC-H2S84>: cont from <WP.MIC-H2S77,H3S2.H4S1-H5S1>

H3S3: Using fwrite and stream_socket_client to send the string to Web-Socket:

Indeed, both calls to fwrite, the only ones that the client ever needs to do, pass strings, to the same | target.

<WP.MIC-H2S77>

H4S1: Establishing the stream-obj:

<?php $socket = stream_socket_server("tcp://localhost:443", $errno, $errstr, STREAM_SERVER_BIND | STREAM_SERVER_LISTEN);
$fp = stream_socket_client("tcp://localhost:443", $errno, $errstr, 30);
if (!$fp) {
    echo "$errstr ($errno)<br />\n";
} else {
	echo "you dun it";
}?>

See the testing log below. This code establishes 1) the scheme for both $address is tcp:// 2) the client specified port must match that of the server 3) the stream must be created, before the client can open an connection. Presently, I’m not able to configure establishing the socket_server line on a different file, even though this is fundamentally | correct.

H4S2: Requiring stream_socket_server:

The next step will be # to move _server to a different file, and see if we can produce ‘you dun it’ remotely, by requiring that file #

H4S3: Preparing to confirm the connection:

Hu: We need a simple conditional that echoes the connection status, or failure, based on an on-conn event, which can be a parse of a potential HTTP-response<Turing>

H4S4: Accepting the connection:

$clientSocket = stream_socket_accept($socket);
if (is_resource($clientSocket)) {
	echo "ah, you dun it again!";
	} else {
		echo "nah, you dun goofed"; 
}

H3S3 H4S2<below>:

H3S4: HTTP-anatomy<fbno>:

// add MIC-anatomy from ch-2

H4S1: Header field lit-rev:

//<a-r>: https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

H5S1: Content-type:

<Wikipedia>: The Media type of the body of the request (used with POST and PUT requests). Eg: Content-Type: application/x-www-form-urlencoded Code example<Khoury, a-r>:

hr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");

H3S5: HTTP.response-syntax:

<ref: C:\wamp64\www\flare\testing-progress\MediaDevices, Github a-r>: 

<!-- http://flare/my.sql-inc/db.conn-inc.php -->
<!-- test-log 
1:24 AM 10/30/22:
	URL test, db-conn test; created new db, swapped in db-name. 
	Test-passed:
		Connection successful! displayed, when this URL is visited. -->
blob:https://flare/ed09a89f-e40a-4b67-8236-2cb9fa94e7cb<!-- https://flare/testing-progress/MediaDevices/blob.URL-SELECT,server.php -->
<!-- dev-notes:
	Listening in a row needs to be temperamental; after a URL is read,
	the listener needs to be incremented to the next row. The script needs
	to recognize when it has read something<sentience>as use that recognition, moment<physics>
	to trigger the next increment. This way, the src is not replaced mid.play-back.-->
<!-- test-prog:-->

Hu: The above is the result of console.log(document.getElementById(“msg”).innerHTML), after this.responseText has been fed into that aspect #<a-rs, both>; curiously, this is displayed, on the front end, as only ‘blob:https://flare/ed09a89f-e40a-4b67-8236-2cb9fa94e7cb’ as a string.

This is because the HTML-compiler<Turing><WP.MIC-H2S55,H3S4>will interpret what is inside the <!– as a comment, and not display it, in pixels.

H4S1: Parsing an HTTP-response for only the explicit.PHP-script,output: 

--> blob:https://flare/ed09a89f-e40a-4b67-8236-2cb9fa94e7cb<!--

Here’s the near | view of what we need to extract from the HTTP-response: we know that there is only one instance of the word blob in any case, and this can be our first cut | token<PHP-shill!><a-r>; the next cut token has to occur after the final char in the necessary URL-str, which can be the first instance of ‘<!–‘ ==>

H5S1: PHP-parse vs JS-parse:

<WP.MIC-H2S64>Hu: The possibility of same-script PHP-parse provides a fallback, that is only possible, because my web-pages are served up first by WAMP, and secondly, by the browser, but JS can call a PHP function, in the script, to selectively | run it, even after initial script execution is loaded<WP.MIC-H2S61, PHP-interpreter> up to the browser, by WAMP. Refer to<WP.MIC-H2S72,H3S5>for this doc #

Analytically, a function call to | PHP would require some action on the PHP-interpreter, both of which, with the browser, are desktop | applications; on the other hand, parsing with JS, which would be acceptable, with a payload this small, would continue existing execution in the browser. Most likely, the difference is insignificant, working with only text, so we can consider this a lat-piv; just go with the fastest, but the prospect of running a PHP.func-call is interessant. The hinge will be based on how easy it is to investigate and call # a PHP-func from a JS-func.

H6S1: The blob parse project has been suspended, because I decided to write the MySQL SELECT directly into a PHP-encap, that runs in the same file, rather than calling an external file, via AJAX, as per #<WP.MIC-H2S72,H3S5>

References:

https://www.php.net/manual/en/function.stream-context-create.php

https://www.youtube.com/watch?v=W7tj0Qlk3rE&ab_channel=ProgramWithGio: 2/10 video, but: Program with Gio: use Inspect->Network to see a list of HTTP requests, eg:

index.php HTTP request when http://personal-dash/index.php is loaded in Brave, via the action of WAMP.
When the index.php 200=OK request is selected, and the Response tab selected, the HTML-loaded is shown. Diff from view.page-source, because this is only the data loaded, as a result of that–request.
Sherif Ramadan

https://pear.php.net/index.php

https://pear.php.net/manual/en/installation.introduction.php

https://pear.php.net/manual/en/package.http.http-request.php

H4S1: Sample HTTP requests in PHP-core:

https://www.php.net/manual/en/stream.examples.php: Example 2: POST request to an https server

Testing logs<fbno>:

H3S3 H4S1:

<!-- testing-log:
11/4/22
	When port set to 1, in socket_client, and 443 in socket_server:
		Warning: stream_socket_client(): Unable to connect to tcp://localhost:1 
		(No connection could be made because the target machine actively refused it)
	client port: 443, socket port: 80
		Warning: stream_socket_client(): Unable to connect to tcp://localhost:443
		''
	client port: 80, socket port: 443
		Display: you dun it
	client port: 443, socket port: 443
		Display: you dun it. 
	Based on this, I think we can conclude, and this is consistent with previous
	literature: port: 80 is always open, so socket port need not be set. 443
	is manually open, and when we set socket_server to 443, a connection *is*
	opened by socket_client; when not, connection is unable to connect. Therefore,
	we can conclude that 1) 443 is probably the best port to use, because it's
	not open by default and 2) socket_server's action of opening the port is working. 
	client port: 442, socket port: 442
		Display: you dun it. 
	client port: 442, socket port: 443
		Warning: stream_socket_client(): Unable to connect to tcp://localhost:442 
		''
	client scheme: tcp:// socket scheme: ws:// ports, both 443
		Warning: stream_socket_server(): Unable to connect to ws://localhost:443 
		''
		Same error, when both are set to ws://
	client scheme: http:// socket scheme http://
		Warning: stream_socket_server(): Unable to connect to http://localhost:443
		Warning: stream_socket_client(): Unable to connect to http://localhost:443
	Based on this, under the local WAMP conditions, only tcp:// for both, works, to 
	establish a connection. 
	When stream_socket_server is commented out entirely:
		Warning: stream_socket_client(): Unable to connect to tcp://localhost:443
		''
	When socket_server is commented out, but moved to a different file, and that file
	is run, and left open to the screen, then this file is run. 
		Still: Warning: stream_socket_client(): Unable to connect to tcp://localhost:443

H3S3 H4S2:

10:04 AM 11/5/22:
	localhost:443, both, and with new stream_socket_accept($socket); integration:
		Both positive "dun its" returned. 
	socket_server changed to :80, only. 
		Warning: stream_socket_client(): Unable to connect to tcp://localhost:443
		And 'nah, you dun goofed'
	stream_socket_accept moved up in the interpreter list, above socket_client:
	localhost:443, both
		Warning: stream_socket_accept(): Accept failed: with 'nah, you dun goofed'
		However, the socket_accept check returns you dun it
	echo $clientSocket;
		Resource id #5

References:

https://www.php.net/manual/en/function.header.php
https://www.php.net/manual/en/function.http-response-code.php
https://www.php.net/manual/en/function.headers-list.php
https://www.php.net/manual/en/function.headers-sent.php
https://www.php.net/manual/en/reserved.variables.httpresponseheader.php

HTTP-reqs:

https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

Adam Khoury

HTTP-response:

https://github.com/yakun-hu/flare/tree/main/testing-progress/MediaDevices

https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/responseText

https://www.w3schools.com/jsref/prop_html_innerhtml.asp

https://www.php.net/manual/en/function.strtok.php

Related posts:

  1. H2S74: Finagling TCP/IP architecture to enable true peer-to-peer domain-less information-ex:
  2. H2S76: PHP.frameworks-lit,rev:
  3. H2S111: Converting p-dash into a general cMS Frame-lib:
  4. H2S75: How to write a Web.Socket-server, from scratch, in PHP:

wordpress_nq07cz

Leave a Reply

Your email address will not be published. Required fields are marked *