Verificando se arquivo de outro servidor existe com cURL php

Verificando se arquivo de outro servidor existe com cURL php

Abaixo utilizo o cURL para verificar se existe, e informo o retorno que eu coleto somente o código do http.
Caso o retorno seja 200, é porque existe!!!

$ch = curl_init($url);
curl_setopt($ch, CURLOPT_NOBODY, true);
curl_exec($ch);
$retCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
curl_close($ch);

return $retCode;

Usar post content json no cURL do PHP

Usar post content json no cURL do PHP

Neste formato abaixo estou passando um array para como atributos do post para ser enviado para uma $URL específica.
Este método

$url = ‘http://www.teste.com.br/teste/’;
$data = array();
$data[‘cod_usuario’] = $cod_usuario;
$data = json_encode($data); #convertendo inputs para json

ini_set(‘MAX_EXECUTION_TIME’, 300);
$ch = curl_init($url);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data); #campos que serão enviados
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); #ativa se for ter retorno do chamada
curl_setopt($ch, CURLOPT_HTTPHEADER, array(‘Content-Type: application/json’)); #tipo do header, neste caso o json
$result = curl_exec($ch); #resultado em caso de retorno
curl_close($ch);

#abaixo estou decodificando o json retornado, mas como está vindo como objeto, adicione o conversor para (array).
$result = (array) json_decode($result);

Retirar o cache do navegador – todas linguagens de programação

The correct minimum set of headers that works across all mentioned clients (and proxies):

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0

The Cache-Control is per the HTTP 1.1 spec for clients and proxies (and implicitly required by some clients next to Expires). The Pragma is per the HTTP 1.0 spec for prehistoric clients. The Expires is per the HTTP 1.0 and 1.1 spec for clients and proxies. In HTTP 1.1, the Cache-Controltakes precedence over Expires, so it’s after all for HTTP 1.0 proxies only.

If you don’t care about IE6 and its broken caching when serving pages over HTTPS with only no-store, then you could omit Cache-Control: no-cache.

Cache-Control: no-store, must-revalidate
Pragma: no-cache
Expires: 0

If you don’t care about IE6 nor HTTP 1.0 clients (HTTP 1.1 was introduced 1997), then you could omit Pragma.

Cache-Control: no-store, must-revalidate
Expires: 0

If you don’t care about HTTP 1.0 proxies either, then you could omit Expires.

Cache-Control: no-store, must-revalidate

On the other hand, if the server auto-includes a valid Date header, then you could theoretically omit Cache-Control too and rely on Expires only.

Date: Wed, 24 Aug 2016 18:32:02 GMT
Expires: 0

But that may fail if e.g. the enduser manipulates the operating system date and the client software is relying on it.

Other Cache-Control parameters such as max-age are irrelevant if the abovementioned Cache-Control parameters are specified. The Last-Modified header as included in most other answers here is only interesting if you actually want to cache the request, so you don’t need to specify it at all.

How to set it?

Using PHP:

header("Cache-Control: no-cache, no-store, must-revalidate");// HTTP 1.1.
header("Pragma: no-cache");// HTTP 1.0.
header("Expires: 0");// Proxies.

Using Java Servlet, or Node.js:

response.setHeader("Cache-Control","no-cache, no-store, must-revalidate");// HTTP 1.1.
response.setHeader("Pragma","no-cache");// HTTP 1.0.
response.setHeader("Expires","0");// Proxies.

Using ASP.NET-MVC

Response.Cache.SetCacheability(HttpCacheability.NoCache);// HTTP 1.1.Response.Cache.AppendCacheExtension("no-store, must-revalidate");Response.AppendHeader("Pragma","no-cache");// HTTP 1.0.Response.AppendHeader("Expires","0");// Proxies.

Using ASP.NET:

Response.AppendHeader("Cache-Control","no-cache, no-store, must-revalidate");// HTTP 1.1.Response.AppendHeader("Pragma","no-cache");// HTTP 1.0.Response.AppendHeader("Expires","0");// Proxies.

Using ASP:

Response.addHeader "Cache-Control","no-cache, no-store, must-revalidate"' HTTP 1.1.
Response.addHeader "Pragma","no-cache"' HTTP 1.0.
Response.addHeader "Expires","0"' Proxies.

Using Ruby on Rails, or Python/Flask:

response.headers["Cache-Control"]="no-cache, no-store, must-revalidate"# HTTP 1.1.
response.headers["Pragma"]="no-cache"# HTTP 1.0.
response.headers["Expires"]="0"# Proxies.

Using Python/Django:

response["Cache-Control"]="no-cache, no-store, must-revalidate"# HTTP 1.1.
response["Pragma"]="no-cache"# HTTP 1.0.
response["Expires"]="0"# Proxies.

Using Python/Pyramid:

request.response.headerlist.extend((('Cache-Control','no-cache, no-store, must-revalidate'),('Pragma','no-cache'),('Expires','0')))

Using Google Go:

responseWriter.Header().Set("Cache-Control","no-cache, no-store, must-revalidate")// HTTP 1.1.
responseWriter.Header().Set("Pragma","no-cache")// HTTP 1.0.
responseWriter.Header().Set("Expires","0")// Proxies.

Using Apache .htaccess file:

<IfModulemod_headers.c>
    Header set Cache-Control "no-cache, no-store, must-revalidate"
    Header set Pragma "no-cache"
    Header set Expires 0
</IfModule>

Using HTML4:

<metahttp-equiv="Cache-Control"content="no-cache, no-store, must-revalidate"/><metahttp-equiv="Pragma"content="no-cache"/><metahttp-equiv="Expires"content="0"/>

HTML meta tags vs HTTP response headers

Important to know is that when a HTML page is served over a HTTP connection, and a header is present in both the HTTP response headers and the HTML <meta http-equiv> tags, then the one specified in the HTTP response header will get precedence over the HTML meta tag. The HTML meta tag will only be used when the page is viewed from local disk file system via a file:// URL. See also W3 HTML spec chapter 5.2.2. Take care with this when you don’t specify them programmatically, because the webserver can namely include some default values.

Generally, you’d better just not specify the HTML meta tags to avoid confusion by starters, and rely on hard HTTP response headers. Moreover, specifically those <meta http-equiv> tags are invalidin HTML5. Only the http-equiv values listed in HTML5 specification are allowed.

Verifying the actual HTTP response headers

To verify the one and other, you can see/debug them in HTTP traffic monitor of webbrowser’s developer toolset. You can get there by pressing F12 in Chrome/Firefox23+/IE9+, and then opening the “Network” or “Net” tab panel, and then clicking the HTTP request of interest to uncover all detail about the HTTP request and response. The below screenshot is from Chrome:

Chrome developer toolset HTTP traffic monitor showing HTTP response headers on stackoverflow.com

I want to set those headers on file downloads too

First of all, this question and answer is targeted on “web pages” (HTML pages), not “file downloads” (PDF, zip, Excel, etc). You’d better have them cached and make use of some file version identifier somewhere in URI path or querystring to force a redownload on a changed file. When applying those no-cache headers on file downloads anyway, then beware of the IE7/8 bug when serving a file download over HTTPS instead of HTTP. For detail, see IE cannot download foo.jsf. IE was not able to open this internet site. The requested site is either unavailable or cannot be found.

Reference: https://stackoverflow.com/questions/49547/how-to-control-web-page-caching-across-all-browsers

Diferença entre $ e $$ em php

Diferença entre $ e $$ em php

$a representa uma variável

Quando utilizarmos $$a, o php pega o conteúdo de $a e representa como uma variável.

Exemplo:

$teste ="bom dia";
$a ="teste";
echo $$a;

Resposta será: bom dia

 

Referencehttps://stackoverflow.com/questions/11504335/what-is-the-difference-between-a-and-a-in-php

CAKEPHP – Criando conditions no paginate com outras tabelas

 

Montando um Paginate com conditions em todas as tabelas

$this->paginate = array(
‘fields’=>’Financeiro.*,Aluno.*,Usuario.*’,
‘conditions’ => $condition,
‘joins’=>array(
array( ‘table’ => ‘aluno’,
‘alias’ => ‘Aluno’,
‘type’ => ‘LEFT’,
‘conditions’ => array(‘Financeiro.aluno_id = Aluno.id’)
),
array( ‘table’ => ‘usuario’,
‘alias’ => ‘Usuario’,
‘type’ => ‘LEFT’,
‘conditions’ => array(‘Aluno.usuario_id = Usuario.id’)
)
),
// ‘contain’ => array(‘Aluno’ ,’Usuario’),
// ‘link’ => array(‘Financeiro’ => array(‘Aluno’ => ‘Usuario’)),
‘limit’ => 30,
‘order’ => array(‘id’ => ‘DESC’)
);

Fazer varredura do HTML no PHP

if (preg_match_all(“#<tr[^>]*>(.*?)</tr>#is”, $html, $matches)) {
foreach ($matches[1] as $linha) {
if (preg_match_all(“#<td[^>]*>(.*?)</td>#is”, $linha, $mat)) {
foreach ($mat[1] as $col) {
// em $row está o conteúdo dos tds desta linha
var_dump($col);
}
}
}
} else {
echo ‘<h3>Nada encontrado!</h3>’;
}

Diferença entre Soap e Rest

SOAP

SOAP é um protocolo de transferência de mensagens em formato XML para uso em ambientes distribuídos. O padrão SOAP funciona como um tipo de framework que permite a interoperabilidade entre diversas plataformas com mensagens personalizadas.

Aplicando este padrão em Web Services, geralmente usa-se o WSDL para descrever a estrutura das mensagens SOAP e as ações possíveis em um endpoint.

Uma das maiores vantagens disso é que várias linguagens e ferramentas conseguem ler e gerar mensagens facilmente. Várias linguagens de programação permitem a geração de objetos de domínio, Stubs e Skeletons a partir da definição do WSDL, permitindo a comunicação remota via RPC através de chamadas a métodos remotod, inclusive com argumentos complexos, como se fossem chamadas locais.

O problema desse padrão, é que ele adiciona um overhead considerável, tanto por ser em XML quanto por adicionar muitas tags de meta-informação. Além disso, a serialização e desserialização das mensagens pode consumir um tempo considerável.

REST

REST é outro um protocolo de comunicação, baseado no protocolo de hipermídia HTTP. Porém ele não impõe restrições ao formato da mensagem, apenas no comportamento dos componentes envolvidos.

A maior vantagem do protocolo REST é sua flexibilidade. O desenvolvedor pode optar pelo formato mais adequado para as mensagens do sistema de acordo com sua necessidade específica. Os formais mais comuns são Json, XML e texto puro, mas em teoria qualquer formato pode ser usado.

Isso nos leva a outra vantagem: quase sempre Web Services que usam REST são mais “leves” e, portanto, mais rápidos.

O problema com o REST pode surgir justamente por causa de suas vantagens. Como a definição do corpo de dados fica totalmente a cargo do desenvolvedor, os problemas de interoperabilidade são mais comuns.

SOAP ou REST?

Aviso: Esta é uma opinião pragmática.

Em geral, SOAP é uma boa opção para instituições com padrões rígidos e ambientes complexos (várias plataformas e sistemas). Muitas ferramentas corporativas (como ESB) tiram vantagem do padrão e possibilitam filtrarem, enfileiramento, classificação e redirecionamento das mensagens trocadas entre sistemas.

No restante, para uso no dia-a-dia, não vejo motivos concretos para não usar REST e Json. Praticamente todas as plataformas e linguagens modernas que conheço suportam esses conceitos e a solução final é muito mais simples do que o equivalente em SOAP.

Além disso, integrações com alto volume de requisições são inviáveis em SOAP. REST é capaz de atender volume e complexidade sem dificuldades, exigindo apenas um mínimo de experiência do desenvolvedor para estabelecer e reforçar os padrões adequados.

Fonte: http://pt.stackoverflow.com/questions/11183/diferen%C3%A7as-de-tipos-de-web-service-soap-rest-xml

Aumentar limite de import de sql do phpmyadmin

Acesse o php.ini do seu PHP , geralmente fica dentro da pasta do servidor apache /php/bin/, abra esse arquivo e faça as seguintes alterações

upload_max_filesize = 250MB
post_max_size = 500MB
memory_limit = 512
max_execution_time = 3600

Após estas mudanças, reinicie o serviço do seu servidor apache para que as alterações tenham efeito!