Iniciar sessão ou registar-se

Tópicos não relacionados com casas ou imóveis

Bugs e truques do fórum

↓ Fundo

61 a 79 de 79   

  1. <
  2. 1
  3. 2
  4. 3
  5. 4
  6. >

  1.  # 61

    Boas,

    Colocado por: hangasNormalmente não está activado nos servidores HTTP por causa da implicações de segurança obvias.


    Nem me lembro que isso existe ;)

    Divirtam-se,
    João Dias e seu gato psicanalista

  2.  # 62

    Essa do "só podia" não entendi. Pode explicar por favor? Note-se que eu fui buscar um pedaço de código java que encontrei na net. Eu costumo trabalhar com coisas de mais baixo nível...muito abaixo do assembly...

    "A computer file is a block of arbitrary information, or resource for storing information, which is available to a computer program and is usually based on some kind of durable storage".

    Colocado por: oxelferUm ficheiro é um conjunto de informação e não somente o seu conteúdo, um servidor web processa-os todos. Como o ferraz faz, além do conteúdo do ficheiro precisa de enviar outra informação e depois processá-la e criar o ficheiro no servidor, e a isto não podemos chamar enviar um ficheiro para um servidor.


    Aquilo que eu faço (a informação extra a enviar) o cliente pode fazer de modo automático por mim. Mas eu também posso fazê-lo se quiser manipular o ficheiro.

    Mas o que me está a dizer é que, se eu enviar um ficheiro para um servidor ele sabe o que automaticamente, certo? Errado (na minha opinião de leigo). O servidor sabe que num request vem alguma coisa no envelope. Mas não sabe o que é. Só a partir do momento em que, programaticamente, eu lhe digo o que fazer com a informação é que o servidor sabe. Até lá é apenas um array de bytes que vêm num envelope.

    O que você refere como enviar um ficheiro de modo automático ou à pata tem a ver simplesmente com marshalling e unmarshalling automático ou manual. Ou existe um marshalling directo (e é o cliente que trata de tudo) do ficheiro e é enviado em comm time já depois do pedido aberto ou então eu manipulo o ficheiro, faço eu o marshall para uma string por exemplo, envio-o por via get (digamos assim) passando por cima do cliente e do lado de lá tenho que processar o que recebi. É claro que isto tem a pequena desvantagem (é verdade) de uma maior quantidade de processamento e de muitos mais parâmetros que que tenho que dar ao servidor para ele saber como tratar a string.

  3.  # 63

    Colocado por: oxelferBoas,



    Mas discorda de quê?

    Quando enviamos um ficheiro para o servidor com um formulário POST e method multipart o servidor não cria o ficheiro?

    Divirtam-se,
    João Dias e seu gato psicanalista

    Se for um Post e não disser ao servidor o que fazer com ele não...o servidor não cria o ficheiro. Se criasse não era necessário (por exemplo) validar se o content é multipart ou não. Nem sequer era preciso fazer override ao doPost

  4.  # 64

    Boas,


    Colocado por: Ferraz OliveiraSe for um Post e não disser ao servidor o que fazer com ele não...o servidor não cria o ficheiro. Se criasse não era necessário (por exemplo) validar se o content é multipart ou não. Nem sequer era preciso fazer override ao doPost


    Fonix, qual parte é que não percebeu?
    Um servidor web ao receber um formulário multipart por post que contém um ou mais ficheiros, cria-os automaticamente!!!
    Não precisa de fazer nada para a criação do ficheiro, a única coisa que normalmente se faz (além das validações) é movê-lo (MOVÊ-LO) para onde queremos, pois o ficheiro é criado numa pasta temporária.
    Este processo é uma das características de um servidor web!!!
    Um servidor web que não crie o ficheiro nestas condições é porque está mal configurado!!!


    Divirtam-se,
    João Dias e seu gato psicanalista

  5.  # 65

    João...será que você não está a ver as coisas do ponto de vista de um utilizador? É que eu estou a ver do ponto de vista que quem implementa web applications e até as coisas mais abaixo que as web applications usam que é o que eu faço na minha vida profissional.
    Será que você não está a usar uma aplicação web em que você simplesmente usa algo que já está implementado do lado do servidor, tipo uma framework? Você constrói o form e faz o submit e no lado do servidor é tudo tratado automaticamente? Não mexe em código do lado do servidor?

  6.  # 66

    1 - no cliente o form faz um submit de um ficheiro num post com content multipart
    2 - os bytes vão via fio até ao servidor
    3 - servidor invoca o servlet que está mapeado para processar o submit
    4 - quando o processamento do post no servlet é invoca o contéudo do post está em MEMÓRIA...é um array de bytes. Só a partir do momento em que o servlet mastiga o array de bytes e abre uma stream para um filesystem é que o ficheiro é gravado. Até lá o ficheiro é um array de bytes. O servlet é que sabe o que é que vai fazer com a stream, e se no método que processa o post você redireccionar (por exemplo) o array de bytes para a resposta, não há cá nenhum ficheiro criado. Você está a pensar tão a alto nível que se esquece que as coisas só acontecem "automaticamente" porque houve "alguém" que, no ponto em que o servlet processa o post, decidiu que o ficheiro ia ser gravado.

    Mas sugiro-lhe o seguinte

    Crie uma aplicação web a partir de um template. No cliente faça um submit de um ficheiro, ponha um breakpoint no método que processa o post no servlet logo na primeira instrução e vá ver aos folders temporários do webserver se o ficheiro está lá e depois falamos. Ah...e a primeira instrução é atirar uma excepção cá para fora. E depois vá ver se o ficheiro foi criado.

    É que você cria aplicações web intra e internet. E eu implemento o que você usa para criar as suas aplicações. Você está num nível mais alto que eu em que tudo aparece de forma "miraculosa". Já tem tudo feito é só usar. E eu é que implemento as coisas "miraculosas".

  7.  # 67

    Boas,

    Ferraz, vamos lá ver uma coisa:
    Um servidor web deve ter determinadas características para ser considerado um servidor web, e uma dessas características é criar um ficheiro temporário quando recebe um ficheiro submetido por um formulário multipart. Se não o fizer não é considerado um servidor web pois não responde aos standards.

    Claro que as coisas não acontecem por milagre, mas o processamento de criar o ficheiro é da responsabilidade do servidor e não da aplicação que o vai usar.

    Divirtam-se,
    João Dias e seu gato psicanalista

  8.  # 68

    Boas,

    Colocado por: Ferraz OliveiraCrie uma aplicação web a partir de um template. No cliente faça um submit de um ficheiro, ponha um breakpoint no método que processa o post no servlet logo na primeira instrução e vá ver aos folders temporários do webserver se o ficheiro está lá e depois falamos. Ah...e a primeira instrução é atirar uma excepção cá para fora. E depois vá ver se o ficheiro foi criado.


    Claro que o ficheiro lá está, porque o servidor web o criou antes de chamar a aplicação web.

    Divirtam-se,
    João Dias e seu gato psicanalista

  9.  # 69

    Boas,

    Como não sei Java, respondo-lhe em php.
    Quando um ficheiro é enviado para o servidor, desde a primeira linha de uma página php temos um array ($_FILES) com as informações de todos os ficheiros que foram enviados.
    Entre outras informações temos:
    O nome do ficheiro original.
    Tipo de ficheiro
    Tamanho do ficheiro
    Nome do ficheiro temporário criado
    Informações de um erro ao fazer o upload do ficheiro.

    Em termos de php não temos de fazer absolutamente nada para criar o ficheiro, o que normalmente se faz é somente mover o ficheiro da pasta temporária para outra pasta (além que qualquer tipo de validação).

    A responsabilidade de processar os uploads é do servidor que fornece as informações necessárias às aplicações para que estas o possam usar.

    Divirtam-se,
    João Dias e seu gato psicanalista

  10.  # 70

    Ah... agora percebi a explicação.
    Estamos a falar de PHP, e ai sim.. é tudo mágico.

    Senão é como o Ferraz afirma. Apenas por puro HTTP não é possível enviar ficheiros sem ser por PUT.
    O que acontece é que a framework PHP faz alguma magia prévia. Tal como faz com as $HTTP_*_VARS.

    E no caso que o João refere, a framework PHP automaticamente faz parse aos conteúdos multipar dos POST, aceita o upload para um local pré-definido e já lá está.
    E isso só existe desde o PHP 4.x.. Antes tinha que ser feito à mão.. ler o conteúdo o multipart, criar o ficheiro, e meter para lá o conteúdo, depois de decoded.


    Agora "as per HTTP" não é assim tão magico. E quando leio servidor web, para mim é um Apache HTTP, IIS por exemplo. O Tomcat já não tanto, porque já faz alguma magia para Java Web Apps. É que nem todos os servidores WEB são LAMPs :)
    Concordam com este comentário: oxelfeR (RIP)

  11.  # 71

    Colocado por: oxelferBoas,



    Claro que o ficheiro lá está, porque o servidor web o criou antes de chamar a aplicação web.

    Divirtam-se,
    João Dias e seu gato psicanalista


    Lá está...você está a usar PHP...uma framework que já está montada e que resolve esse problema de forma "automática". Se usarem algo como por exemplo jsp ou asp.net ou gwt ou qualquer outra tralha em que só a base exista, então você tem que a fazer "à unha"...que é o que eu faço! Percebe? Um apache é um webserver e não grava ficheiro nenhum automaticamente. Os servlets que usamos para desenvolver aplicações que corram num apache é que fazem isso!
    Nada acontece de forma automática. No caso do PHP é a PRÓPRIA framework que já está "formatada" para "automaticamente" gravar o ficheiro.

    Você está a confundir webserver (apache, jetty, liferay, weblogic, drupal, etc) com a framework que é usada para processar as coisas. É a framework que diz ao webserver "olha...grava-me esta treta". O webserver não grava nada automaticamente.

    Ah...e eu não percebo patavina de java! Como lhe disse, tudo o que escrevi aqui foi resultado de pesquisas na net!

    Um conselho
    Concordam com este comentário: oxelfeR (RIP)

  12.  # 72

    Boas,


    Colocado por: hangasE isso só existe desde o PHP 4.x.. Antes tinha que ser feito à mão.. ler o conteúdo o multipart, criar o ficheiro, e meter para lá o conteúdo, depois de decoded.


    Antes existia o $HTTP_POST_FILES.
    Anterior ao 3 não sei porque acho que nunca utilizei.

    Colocado por: hangasÉ que nem todos os servidores WEB são LAMPs :)


    (embora não dê para essa guerra)
    Servidores web? Nem todos são, mas a grande maioria são-no.

    Divirtam-se,
    João Dias e seu gato psicanalista

  13.  # 73

    Colocado por: oxelferBoas,
    (embora não dê para essa guerra)
    Servidores web? Nem todos são, mas a grande maioria são-no.

    Divirtam-se,
    João Dias e seu gato psicanalista


    Agora perdi-me João! Desculpe! A grande maioria dos servidores web é o quê? LAMP?

  14.  # 74

    Boas,

    Colocado por: Ferraz OliveiraAgora perdi-me João! Desculpe! A grande maioria dos servidores web é o quê? LAMP?


    Yeps

    Divirtam-se,
    João Dias e seu gato psicanalista

  15.  # 75

    Se a definição de LAMP que o acronym finder dá é Linux/Apache/MySql/Perl,Php,Python então um servidor Apache que esteja a correr em Windows não é LAMP.

    Tendo em conta que 78% dos pcs worldwide são Ms e só menos de 2% é que são GNU Linux (estimativas), pergunto-me como é que você pode afirmar que a maioria dos webservers são LAMP.

  16.  # 76

    Boas,

    Colocado por: Ferraz OliveiraTendo em conta que 78% dos pcs worldwide são Ms e só menos de 2% é que são GNU Linux (estimativas), pergunto-me como é que você pode afirmar que a maioria dos webservers são LAMP.


    Corrijo:
    A grande maioria dos servidores web disponibilizados por empresas de webhosting são LAMP.

    Divirtam-se,
    João Dias e seu gato psicanalista

  17.  # 77

    Boas,

    Colocado por: oxelferCorrijo:


    Há vícios difíceis de perder :(

    Divirtam-se,
    João Dias e seu gato psicanalista

  18.  # 78

    Colocado por: oxelferBoas,



    Corrijo:
    A grande maioria dos servidores web disponibilizados por empresas de webhosting são LAMP.

    Divirtam-se,
    João Dias e seu gato psicanalista

    Não disponho de dados para rebater :-). Vou ter que confiar na sua palavra. :-D

    Você, dado que trabalha com esse tipo de aplicações, seguramente saberá isso melhor que eu!

    Cumprimentos

  19.  # 79

    Boas,

    Colocado por: Ferraz OliveiraNão disponho de dados para rebater :-). Vou ter que confiar na sua palavra. :-D


    LOL
    É melhor não o fazer.
    Ultimamente esta coisa que está acima do pescoço não é de fiar muito.

    Colocado por: Ferraz OliveiraVocê, dado que trabalha com esse tipo de aplicações, seguramente saberá isso melhor que eu!


    Já trabalhei mais, actualmente faço muito pouco :(

    Divirtam-se,
    João Dias e seu gato psicanalista

    61 a 79 de 79

  1. <
  2. 1
  3. 2
  4. 3
  5. 4
  6. >
← Voltar à lista de todas as Discussões
 
0.0327 seg. NEW