On 05/17/2018 09:03 PM, Taco Hoekwater wrote:
>
>
>> On 17 May 2018, at 10:31, Taco Hoekwater wrote:
>>
>> Anyway, perhaps someone can answer me this? I tried the ffi/curl code,
>> and the network stuff works, but only when I comment out the write
>> callback:
>>
>>
> On 17 May 2018, at 10:31, Taco Hoekwater wrote:
>
> Anyway, perhaps someone can answer me this? I tried the ffi/curl code,
> and the network stuff works, but only when I comment out the write
> callback:
>
> lcurl.curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION,
>
On Thu, May 17, 2018 at 9:54 AM, Taco Hoekwater wrote:
>
>
Doing https would need openssl support, which is unlikely to
> ever be built into luatex.
>
> We could provide a ffi wrapper (once ffi is stable)
or a swiglib wrapper as module.
Something to discuss at meeting.
--
On 5/17/2018 9:54 AM, Taco Hoekwater wrote:
On 17 May 2018, at 09:39, Taco Hoekwater wrote:
On 17 May 2018, at 09:32, Ulrike Fischer wrote:
Am Wed, 16 May 2018 14:23:42 +0200 schrieb Taco Hoekwater:
Or use luasocket, which is included in the
> On 17 May 2018, at 10:20, Ulrike Fischer wrote:
>
> Am Thu, 17 May 2018 09:39:47 +0200 schrieb Taco Hoekwater:
>
Or use luasocket, which is included in the luatex binary:
>
>>> But I'm right that this works only with http and not with https?
>
>> Works ok for me.
Am Thu, 17 May 2018 09:54:25 +0200 schrieb Taco Hoekwater:
>> Works ok for me. Did you test?
>
> Oh, sorry. It seems it is sneakily rewriting the https:// to http://,
> and so does not _actually_ work.
Ah. This explains why it seemed to work for
https://httpbin.org/html, http://httpbin.org/html
Am Thu, 17 May 2018 09:39:47 +0200 schrieb Taco Hoekwater:
>>> Or use luasocket, which is included in the luatex binary:
>> But I'm right that this works only with http and not with https?
> Works ok for me. Did you test?
I tried a few links and always got 301 back regardless if they exist
or
> On 17 May 2018, at 09:39, Taco Hoekwater wrote:
>
>
>
>> On 17 May 2018, at 09:32, Ulrike Fischer wrote:
>>
>> Am Wed, 16 May 2018 14:23:42 +0200 schrieb Taco Hoekwater:
>>
>>> Or use luasocket, which is included in the luatex binary:
>>
>> But
I too have the impression it is working for both.
Hans van der Meer
> On 17 May 2018, at 09:39, Taco Hoekwater wrote:
>
>
>
>> On 17 May 2018, at 09:32, Ulrike Fischer wrote:
>>
>> Am Wed, 16 May 2018 14:23:42 +0200 schrieb Taco Hoekwater:
>>
>>> Or
> On 17 May 2018, at 09:32, Ulrike Fischer wrote:
>
> Am Wed, 16 May 2018 14:23:42 +0200 schrieb Taco Hoekwater:
>
>> Or use luasocket, which is included in the luatex binary:
>
> But I'm right that this works only with http and not with https?
Works ok for me. Did you
Am Wed, 16 May 2018 14:23:42 +0200 schrieb Taco Hoekwater:
> Or use luasocket, which is included in the luatex binary:
But I'm right that this works only with http and not with https?
--
Ulrike Fischer
http://www.troubleshooting-tex.de/
> On 16 May 2018, at 15:41, Hans Hagen wrote:
>
> On 5/16/2018 2:58 PM, Hans van der Meer wrote:
>> Beste Taco,
>> Ik probeer jouw oplossing maar er gebeurt nog iets raars. Ik krijg inderdaad
>> 200 resp. 404 terug bij bestaande niet-bestaande Uri’s. Maar ik krijg wel
>>
On 5/16/2018 2:58 PM, Hans van der Meer wrote:
Beste Taco,
Ik probeer jouw oplossing maar er gebeurt nog iets raars. Ik krijg
inderdaad 200 resp. 404 terug bij bestaande niet-bestaande Uri’s. Maar
ik krijg wel een error die aan het eind van de run gegenereerd wordt.
Heb jij enig idee waar ik
Beste Taco,
Ik probeer jouw oplossing maar er gebeurt nog iets raars. Ik krijg inderdaad
200 resp. 404 terug bij bestaande niet-bestaande Uri’s. Maar ik krijg wel een
error die aan het eind van de run gegenereerd wordt. Heb jij enig idee waar ik
dat zou moeten zoeken? Als ik de call naar
Or use luasocket, which is included in the luatex binary:
\startluacode
content, status, authinfo = socket.http.request{
method = "HEAD",
url =
"http://hansvandermeer.myqnapcloud.com/archive/denhaag/hga-dtb-1869-6040.pdf”
}
print (status)
\stopluacode
prints ‘404’ in this case.
On 05/16/2018 11:23 PM, Hans van der Meer wrote:
> I would be satisfied when a returned 404 error code will be handled
> within a reasonable (configurable) time delay. As for redirection, there
> I would not mind if it is not included.
> Restrictions like that are not a problem for me, because
I would be satisfied when a returned 404 error code will be handled within a
reasonable (configurable) time delay. As for redirection, there I would not
mind if it is not included.
Restrictions like that are not a problem for me, because this is for building a
pdf that accesses many internet
On 05/16/2018 09:31 PM, Hans van der Meer wrote:
> I tried to determine the existence of a file on the internet. See the
> following macro call:
>
> % Test if file exists.
> \edef\theurl{\linkprotocol://\urlbase\xmlatt{#1}{link}\thesuffix}
> \doiffileelse
>
I tried to determine the existence of a file on the internet. See the following
macro call:
% Test if file exists.
\edef\theurl{\linkprotocol://\urlbase\xmlatt{#1}{link}\thesuffix}
\doiffileelse
{\theurl}
{\verbose{HVDM-PEV-TEST}{file
19 matches
Mail list logo