Viewed   99 times

I'm trying to receive a gzip'ed version of a page through file_get_contents in php 5.2.9

I was able to do it using fopen with the following code:

    $opts = array(
  'http'=>array(
    'method'=>"GET",
    'header'=>"Accept-language: enrn" .
              "Accept-Encoding: gziprn"
  )
);

$context = stream_context_create($opts);
ob_start();
$fp = fopen('http://example.com', 'r', false, $context);
fpassthru($fp);
fclose($fp);
$content = ob_get_contents();
ob_end_clean();

That works, but I was hoping there was a way I could do it using file_get_contents instead.

Thanks.

 Answers

5

Have you tried this?

$content = file_get_contents('http://example.com',false,$context);
Wednesday, October 5, 2022
 
oligg
 
4

A few years ago I benchmarked the two and CURL was faster. With CURL you create one CURL instance which can be used for every request, and it maps directly to the very fast libcurl library. Using file_get_contents you have the overhead of protocol wrappers and the initialization code getting executed for every single request.

I will dig out my benchmark script and run on PHP 5.3 but I suspect that CURL will still be faster.

Friday, December 16, 2022
 
3

In your url try:

http://user:[email protected]/ 

(append whatever the rest of the URL for your API should be)

Friday, November 4, 2022
 
matoran
 
49

This is what worked for me. I would however appreciate any comments or answers that can expand on what some of these choices actually mean!

Open the MMC console on the Remote Desktop server you want to generate the certificate for, and add the Certificates snap-in, selecting the "Computer account" and "Local computer" options. Go to Personal/Certificates, right-click and select All Tasks -> Advanced Operations -> Create Custom Request.

Click Next. Select "Proceed without enrollment policy" and click Next again.

For Template, I chose "(No template) CNG key". I have found some posts saying that you need to choose the Legacy option instead, but I don't see any reason why this would be necessary and indeed the CNG option worked as expected.

For Request format, I chose PKCS #10.

In the Certificate Information dialog, click on Details and then Properties.

In the General tab, add a friendly name and a description.

In the Subject tab, add the fully-qualified DNS name of the server (or server farm) as the "Common name". Note that a certificate request with an unqualified name (whether as the subject or as an alternative name) is likely to be rejected by the certificate signing authority.

I also added Organization, Locality, State, and Country. If the server has more than one DNS name, you may also wish to add the alternative names at this point.

In the Extensions tab, under Extended Key Usage, add Server Authentication. I did not make any other changes in this tab. (Some posts say you should also include Code Signing, presumably so that you can sign RDP files; this does not appear to be necessary, as I was able to use rdpsign to sign my RDP file and the certificate was accepted by the Microsoft client.)

In the Private Key tab, under Key options, I changed the key size to 2048 and set the flag for "Make private key exportable". This is necessary because the Deployment Properties dialog will only allow you to import a certificate as a file, the certificate and private key will then be transferred to the session host server(s). I did not make any other changes under this tab.

After dismissing the Properties dialog, click Next. Save the request as a file in Base64 format. Click Finish. Submit the request to your certificate authority, and once the new certificate has been generated, download it into a .crt file.

In the MMC console, right-click on Personal/Certificates and select All Tasks -> Import. Select the response file and click Next. Check that the Personal store is selected and click Next. Click Finish. Click OK when you get the message saying the import was successful.

Double-click the new certificate to open it. Check that the certificate is shown as valid; if not, you may need to import an intermediate CA certificate provided by your certificate authority. Also check that the certificate shows the message "You have a private key that corresponds to this certificate" on the General tab.

Right-click on the new certificate and select Export. Click Next. Select the option to export the private key and click Next.

In the Export File Format dialog, PKCS#12 was the only available choice; I used the de settings, i.e., I left the "include all certificates in the certification path if possible" option checked and I left all the other options unchecked. Click Next. (Edit: in Server 2019 the "Enable certificate privacy" option is also enabled by de, this is described here and as far as I can see you may as well leave it enabled.)

Choose the option to protect the private key using your user account and click Next. Enter a file name and click Next. Click OK when you get the message saying the export was successful. (Note that the file will be saved by de to the same location you imported the certificate file from.)

Going back to Server Manager and the Deployment Properties wizard, select the "RD Connection Broker - Enable Single Sign On" option and click "Select existing certificate". Choose the exported .pfx file and select the mandatory "Allow the certificate to be added to the Trusted Root Certification Authorities certificate store on the destination computers" option. Click OK. Click Apply.

NB: in order for the certificate to be used when clients connect, you must install it for the "Enable Single Sign On" option rather than, as I originally assumed, the "Publishing" option. (You don't have to actually use SSO, you can configure whether SSO is attempted via group policy at the client end.)

As described here, you can most easily check what certificate is being served to clients by connecting via the IP address of the server rather than the name.


Additional references:

Configuring certificates and single sign-on, especially the section titled "Common Mistakes Creating Certificates".

Securing RDS with certificates.

Thursday, October 13, 2022
 
zakmck
 
33

Running VS Code this way doesn't establish bidirectional communication with your remote server, it only pulls the files you tell it to open.

To establish this bidirectional connection, I use FUSE and SSHFS on my mac (OSX FUSE). You can mount a remote directory to a local one through an SSH tunnel

sshfs [email protected]:port/path/to/remote/working/dir /path/to/local/working/dir

This allows you to access those remote files on your local machine. Opening VS Code in this local directory allows you to access and edit files on the remote server, using a local application.

Friday, October 28, 2022
 
chlebek
 
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :